Apparatus and method for enabling rapid configuration and reconfiguration of a robotic assemblage

ABSTRACT

Modular components form a robotic assembly, the mod-components include modules and tools, each have a set of functions and capabilities, are rapidly configured-reconfigured to function cooperatively, creating a configurable robotic assemblage. Each mod-component incorporates a standardized connector mating with any other standardized connector in an interchangeable manner providing mechanical stability, power, and signals therebetween. Each mod-component incorporates a processor, data storage for mod-component identity, status, and programmable functionality, and for responding to commands. Storage is reprogrammed while the robot is operational, altering both commands and responses. After interconnection, inter-module power and communication are established and each modular component identifies itself and its functionality, thereby providing “plug and play” configuration.

This application is a continuation of U.S. patent application Ser. No.12/932,171, filed Feb. 19, 2011, entitled “A Submersible RoboticallyOperable Vehicle System for Infrastructure Maintenance and Inspection,”now pending, the contents of which is incorporated herein by referencethereto.

The present invention relates generally to systems, devices and methodsfor designing and controlling configurable robots. More specifically,the present invention relates to an apparatus and architecture capableof both manual (human-guided) and automatic (programmed,‘self-controlled’ or autonomous) operation; an apparatus incorporating aplurality of interchangeable and interconnected modules and a pluralityof interchangeable tools, intelligent closed-loop sensing and control,coordination, synchronization and optimization of simultaneousactivities performed by a plurality of attachments, and autonomousdetection and avoidance of obstacles and other deviations by articulatedattachments. The system architecture and apparatus are intended forrobotically-operable remote vehicles to effect the inspection andremediation of infrastructures that are not easily exposed, includingunderwater or subterranean conduits, pipe networks, dams, basins,abutments, ship hulls, tanks and related infrastructure, although theinvention may be applied to a broad range of robotic and ROVtechnologies and a wide variety of work surfaces (typically aconstructed surface). Hereinafter, we use the term “submergedinfrastructure” to refer to any infrastructure that is not easilyexposed. As applied to infrastructures herein, the term “remediation”refers to any process of repair, rehabilitation, modification,decommissioning, or physical enhancement of that infrastructure,although typically it will refer to a remedying response to damage orundesired changes, irrespective of source. As used herein, the term“debris” refers to any material to be removed from the area of theinfrastructure, including solid debris, sludge, attached livingorganisms, damaged portions of the infrastructure, and so on.

BACKGROUND OF THE INVENTION

Our nation faces a multi-trillion dollar problem in deterioratedinfrastructure. The submerged or subterranean portion of many if notmost decades-old distribution pipelines, a portion often out of sightand out of mind, is at great risk and in dire need of maintenance,especially cleaning. Affected business and municipal sectors includepower generation, petroleum, water, and wastewater management. Analyzingthe need, clarifying by example, establishing requirements, andidentifying the limitations and disadvantages of the prior art in termsof those requirements can best accomplish proper understanding of theseunsolved issues.

When designated for periodic maintenance, infrastructure remediation isoften postponed due to lack of budget in the face of the inefficienciesand high costs of available, prior art solutions. Such postponement onlyfurther complicates the maintenance problem and increases costs when theproblem is eventually addressed. An apparatus, able to operate at highefficiency and low cost, is required in order to change maintenance from“often deferred” (e.g., maintenance performed when unavoidable and whenbudget and other constraints permit) into “routine” (i.e., periodicallyscheduled maintenance). The infrastructure could then be included inscheduled plant maintenance procedures, resulting in ongoinginfrastructure operation at original design specification.

Furthermore, the engineering of the original designs and structurestends to become degraded as living organisms encounter and exploit thesecreated ecological niches, for example, as Zebra Mussels adhere to andgrow within conduits. Such ‘marine fouling’ has become a significant andcostly problem, and serves as a prime example of both the operation ofevolution and of unintended and unsuspected consequences.

The power generation sector depicts one example of the enormity of theproblem of fouling and attendant deterioration of a submergedinfrastructure. High volumes of water are required in steam electricgeneration plants to remove waste heat from steam condensers. Aboutone-half of all larger power plants utilize an open loop (a.k.a.oncethrough) cooling system (FIG. 2) for this purpose (versus closedloop—for example, recycling water in cooling towers). These systemsincorporate submerged intake and discharge conduits, highly susceptibleto fouling, and raise environmental concerns.

Effective conduit size is dramatically reduced by even a relativelysmall amount of fouling on the inside of any conduit. Over and above thereduction of volume, the rough surface of fouling creates friction,causing internal turbulence and effectively compounding the restrictionof flow rates. Pumping pressure must then increase to restore the flowrates to that required for cooling.

Unfortunately, achieving higher flow rates via increased pumpingpressure requires an exponential increase in pumping horsepower, and inthe associated costs. A single large power plant might have to divertmillions of dollars worth of electricity for such pumping; electricitythat otherwise could be placed onto the power grid. The extra pumpingpressure then also puts greater strain and wear on the infrastructure,decreasing its safety and operative life.

Left un-maintained, any growing restriction in diameter will eventuallyovercome the ability of pumps to provide the required water volume andcompensate for the restriction. Plant boiler heat must then be reducedto relieve the potential of backpressure on the steam turbines. Reducingboiler heat impacts electricity production, creating a second source ofrevenue loss.

Using pumping pressure to increase flow rates has a negativeenvironmental impact as well. As flow rates increase, plankton, fish oreven marine mammals are more likely to become sucked into these conduitsand die. Regulatory bodies, seeking compliance with the Clean Water Act,and to mitigate entrainment among other issues, are proposing regulatorylimits to cooling water flow rates (see, for example, Fish Protection atSteam Electric Power Plants, Electric Power Research Institute, 2009).The removal of marine fouling and sediments from cooling water conduits,so as to increase flow volume, will be the only remaining alternative toincrease steam condenser performance.

However, removal of marine fouling is a complex problem. Conduits mayhave a variety of cross-section geometries that may incorporate angles,changes in diameter, and obstacles. Obstacles may include debris, brokenor misaligned infrastructure (such as joints), or infrastructureprotuberances (such as curves, slopes, corners, valve bodies andgateways).

When removing marine fouling, the calcified “footprint” deposited bycrustaceans must be completely removed, as any remaining traces willsupport a rapid re-infestation. This complete removal must beaccomplished without damaging the underlying work surface. Fouling alsonever—or ‘almost never’—occurs in a uniform layer. During removal,varying thicknesses and densities must be detected and propercorrections made to the rate of axial transit through the conduit, the“bite” of the debris removal mechanisms, and debris recovery processingrates. New regulatory compliance requirements for debris disposal alsoimpact these adjustments.

The volume of debris removed in the remediation of a larger conduit, mayapproach a ton per lineal foot. An individual chunk of dislodged debris,falling to the floor (i.e., the “invert”) of the conduit, may encompassseveral cubic feet, weigh hundreds of pounds, and create a verysignificant work process obstacle. It also may pose a significant safetyhazard to a human diver in an enclosed environment, particularly ifvisibility is poor, as it tends to be when water is turbid and lightingis both restricted and limited.

Extensive research regarding submerged infrastructure remediation hasidentified the failure modes and inadequacies of prior art. The examplein the last section, and focus on submerged pipes or conduits(exemplifying a common type of submerged infrastructure), isillustrative of prior art limitations. The overall failure of the priorart for remediation of submerged infrastructures can be summarized bythe simple fact that labor-intensive manual procedures are and willremain central (“DAM Good ROV”, Oceanology Today, Jan. 1, 2006,especially the second paragraph). No prior art device eliminates theneed for manual procedures performed by divers and surface crews withoutsignificant disadvantages and limitations (either to address intendedfunctionality or to provide a complete solution).

Requirements for remediation success in the submerged environmentinclude business metrics that are characterized by cost, safety andefficiency. These metrics impact the ability of industry and governmentto implement any form of remediation and may be broken down intofunctional requirements. For a given remediation approach to beultimately effective, it must at least include and address Inspection,Navigation, Scalability, Optimization, and Performance.

These requirements will be referred to jointly via the acronym “INSOP”hereinafter. INSOP provides a common reference point from which toreview alternative approaches for remediation of infrastructures.

Until the disclosure of this invention, limitations of prior art havefailed to achieve the performance automation required to meet safety,cost or efficiency benchmarks. This failure prevents industry orgovernment from remediating infrastructure in any meaningful way.Apparatus in the prior art may be classified into (1) devices for manualuse, (2) semi-automated devices, and (3) fully-automated devices.

Manual methods either incorporate de-watering (as used herein , the term“de-watering” is used broadly to mean removing water, sewage, mud, oil,sludge, or other material so as to expose a submerged or otherwiseunexposed infrastructure) to allow traditional forms of remediation, orincorporate the use of divers. Divers obviously are not automatedapparatus and, at best, use diver-operated tools. More importantly,divers always must put their lives ‘at risk’ in hazardous environmentsand in particular, the penetrating into long conduits where there is nodirect access to the surface.

Semi-automated methods involve a mechanical apparatus having some formof automated control that makes it less reliant upon diver-operation.These require a user's immediate and continued attention at the remoteor monitoring end of the mechanical apparatus, and generally alsorequire considerable experience and skill in order to correctlyinterpret a limited and indirect set of signals into a reasonableapperception of the events and conditions at the ‘cutting edge’ of theremote apparatus. The further removed, and the more different, theenvironment is from that experienced by the operator, the more likely itwill be that interpretation will introduce errors. Furthermore,semi-automated methods still require divers to overcome limitations ofthe mechanical apparatus (e.g., tasks the apparatus cannot perform) orto correct failures in its automated control apparatus. The more removedthe operator is from both the apparatus and the environment, the morelimited the operator's knowledge of the actual conditions—of theenvironment and of the apparatus—will be; and the more likely it becomesthat an unanticipated and un-sensed divergence from the presumedcondition will give rise to a problem or even a disaster.

Fully automated methods do not require either an operator's or a diver'simmediate and continual attention and continued involvement, but arelimited in the types of tasks or environments in which they can perform.For example, the prior art may disclose an apparatus with the ability toperform some level of inspection in an automated fashion, but the sameapparatus cannot perform remediation. Alternatively, the prior art maydisclose an apparatus with the ability to remediate a round, smalldiameter conduit, but unable to negotiate obstacles. In all fullyautomated examples (i.e., autonomous) of prior art apparatus forsubmerged infrastructure remediation, (e.g. power plant coolingsystems), divers must be used to compensate for numerous limitations, aserious, hazardous, and costly disadvantage.

Submerged infrastructure may be manually remediated by de-watering or byusing divers. De-watering permits remediation by traditional land-basedtechniques. Unfortunately, as infrastructure ages it becomes morefragile and de-watering case histories, chronicling significantstructural damage and even collapse, have made de-watering a practice oflast resort. Furthermore, the nature of the submerged infrastructure orthe material in which it is submerged may make de-watering impracticalor even impossible. Deploying divers is the oldest, and still perhapsthe most prevalent practice to either avoid de-watering, or to remediateinfrastructure where de-watering is not an option.

The manual method of using of divers (FIG. 1A) is the lowest commondenominator, and least efficient means to meet INSOP functionality. Ithas significant disadvantages and limitations. Divers are dependent onvisibility for inspection and navigation, which decreases rapidly as afunction of turbidity, so that divers must rely on “feel” by the use ofhands or feet. Navigation is a further limited by available air supply,tethers, support divers, and safety requirements. Scalability is limitedby diver's reach, which must be augmented by erecting scaffolding andadding additional dive teams. Divers are limited to work processes thatcan be performed using hand-held or handcontrollable implements, andwork optimization is limited by human perception, motor control, andresponses. Performance is a function of environmental conditions(pollution, temperature, clarity and current); of manual labor,susceptible to fatigue caused by the heavy weight belts that must beworn to offset the kickback of hand-operated implements; and the numberof divers that can work within confined conditions without mutualinterference and increased hazard.

The prior art includes apparatus to help overcome diver limitations. Fordivers using water blasters, one such approach is to increase theablative capability of a given water pressure by replacing the fixed fanspray pattern of the water jet with a specialized nozzle (see, forexample, Phovarov, U.S. Patent Pub. No. 2006/0151634 A1). Given thelimitations of the divers as explained above, positioning errors resultin unacceptable abrasion to the work surface by the more powerfulcutting action. Limitations include the lack of means to exactlyposition this nozzle to the work surface, control the amount ofabrasion, and to control uniformity.

Another prior art approach (see, for example, Templet, U.S. Pat. No.5,431,122), intended to improve diver productivity in the rate of theremoval of bio-fouling, resulted in an apparatus resembling anunderwater lawn mower. A limitation of this apparatus was the inabilityto cut more than a “swath” of a few feet wide in any single pass,requiring multiple passes. Other limitations included the lack ofnavigation aids to maintain a straight cutting swath, blinding of thediver caused by the turbidity of machine operation, and no means toprevent the deadly potential of crushing or drowning of the diver byentanglement should power to the machine be lost and it free falls fromthe work surface.

To overcome the limitations of the manual performance of divers, priorart has introduced semi-automated methods in the creation of apparatusthat, for example, has incorporated mechanical scrapers or water jetsfor debris removal. Such apparatus may be, for example, towed by wirecable, pushed by hydraulic pressure, or moved by selfpropulsion.Semi-automated capability ranges from non-intelligent apparatus such aspipeline pigs (FIG. 1B) or other cleaners, to the Remote OperatedVehicle (“ROV” hereafter) utilizing the intelligence of a human being asits operator (FIG. 1C). A general limitation of this method is that allsemi-automated approaches still must incorporate diver-operation anddivers to overcome limited functionality.

Pipeline pigs (see, for example, Couchman, et. al., U.S. Pat. No.6,538,431 B2), proven successful in closed systems such as oilpipelines, have been adapted for use in submerged infrastructure such asconduits. The pipeline pig, propelled by hydraulic pressure, breaksdebris loose from the conduit walls as it is forced through the conduit.One limitation of these devices is they impede operational flow inrequiring a bulkhead to be placed over the conduit mouth to complete theseal with the conduit.

Disadvantages and limitations of pigs are numerous. The pig simplypushes ahead, without any ability to acquire data about the environmentand work surface, or to analyze or control the remediation work processas it proceeds. Without the ability to remove accumulated debris or tooptimize work processes in response to conditions, accumulation buildsin the path of the pig until such time as it becomes stuck. This furthercreates a navigation problem, as the pig, unable to avoid an obstacle,merely crashes into it. Pigs are not a scalable solution: A differentsize of pig is required for each size of conduit diameter. As diametersincrease, the pig becomes disproportionately less effective. Furtherdisadvantages that impact performance include a lack of means to insertitself into a conduit, supply its own hydraulic pressure, completelyclean a conduit in a single pass, free itself when stuck, or to recoverthe debris that it has dislodged. The Sea Pig (Pipeline Digest, Jul. 4,1983, “A pig for every pipe”) exemplifies the above disadvantages andlimitations. This multi-ton projectile, the largest pig of its time, waseventually abandoned for its inability to adequately clean a meretwelve-foot conduit as well as for its tendency to get stuck in theconduit.

Another prior art approach uses the operational flow of water harnessedto rotate mechanical scrapers in the attempt to overcome limitations ofthe pig (see, for example, Crocco, U.S. Pat. No. 5,146,644). Onelimitation of this prior art is the requirement of flowing water torotate fan blades as a (ineffective) source of power. Another limitationis the use of rotating mechanical scrapers without means to preventtheir jamming up when encountering a large clump of debris and causingthe device to become stuck.

Yet other prior art uses a wire tow cable as a means to move a cleaningapparatus. One such prior art approach (see, for example, Haynes, U.S.Pat. No. 2,201,680) uses the forward progress of the apparatus as themeans to power the rotation of mechanical scrapers. In addition torequiring a tow cable, other limitations include the requirement ofmeans to divide towing power between moving the apparatus forward, androtating its scrapers. This division increases the risk of the apparatusgetting stuck or breaking the tow cable.

To reduce the strain of the towing cable, other prior art used externalhydraulic power to rotate the scrapers (see, for example, Latall, U.S.Pat. No. 3,740,785). One limitation is the need to supply hydraulicpower through a long hose from the surface down to the rotating thescraper motor. Line loss through the hose results in significant powerdrop. Yet another prior art approach (see, for example Clavin, U.S. Pat.No. 4,027,349) suggested compound rotation as a means to provide somelatitude in engaging varying amounts of debris and slight variations inthe size of conduits. A set of arms rotated around the axis of theconduit and presented a set of spring-loaded and spinning scrapers toride over variations in the conduit surface. These limitations representconsiderable complexity in apparatus, yet do not provide other thanpassive means to detect and overcome even minimal surface variations,let alone large obstacles.

Furthermore, compound rotation doubles hydraulic power requirements.Still other prior art (see, for example, Murphy, U.S. Pat. No. 5,069,722or Rufolo, U.S. Pat. No. 5,444,887) has elaborated upon the singleapparatus to include support equipment such as cranes, tow cableguidance systems, and catch basins to try and capture some portion ofloosened debris.

Another body of proposed prior art has attempted to use water jettingtechnology to replace mechanical scrapers. In principle, water jets donot need to make direct contact with the work surface and are notsusceptible to getting the apparatus stuck. Early versions of the waterjet apparatus incorporated a reduced diameter, sled-like frame designedto enable towing by wire. A disadvantage of this approach was the“kickback” of the jets, buffeting the sled, and causing the sled runnerto get stuck at the joints between sections of conduit. The cable wouldsometimes snap, or the jets would to stay in one place too long andabrade the surface. Yet other prior art exchanged the sled for a “pipecrawler”. Motorized wheels and auxiliary propulsion allowed for a morereliable engagement with the conduit surface and this created a moreconstant transit (see, for example, Hammelmann, U.S. Pat. No. 3,155,319and Geppert et.al., Patent Pub. No. 2010/0139019 A1). This required yetmore motors, increasing power requirements and line loss.

The above prior art, consisting of both non-intelligent andsemi-automated methods, beyond the various individual limitations anddisadvantages, fail to address INSOP requirements. This failuremanifests in an over dependence upon manual methods, such as diversbelow and large support crews above the surface. With over dependency onmanual methods and human participation, these examples of the prior artbecome economically infeasible.

A Remote Operated Vehicle (“ROV” hereinafter) incorporates theintelligence of a human operator for control. An ROV (FIG. 1C) is asubmersible vehicle featuring an umbilical that serves as a tether and aconnection to a surface source of power and human control that is aupTented by closed circuit video capability.

ROV technology has a growing application in the remediation of submergedinfrastructure as disclosed, for example, in “Remotely Operated Vehicle[ROV] Technology: Applications and Advancements at Hydro Facilities,”Electric Power Research Institute (EPRI), 2002. This EPRI studyidentifies basic types of ROV and discusses their relative operationaleffectiveness.

The study differentiates operational activities into instances where:(1) only divers can perform the operation (i.e., purely manual means);(2) at least one diver must assist the ROV (i.e., semi-automated means);and (3) divers can be completely replaced by an ROV (i.e., fullyautomated means). The study concludes that the ROV has usefulness forinspection and navigation purposes, but has significant limitations inthe inability to perform any maintenance or repair. One cause has beenthat prior art ROV design has required adapting third-party attachments(such as manipulators) to the body of the ROV as a means to accomplishany work process, and a lack of modularity (e.g., an ROV is either aswimming vehicle or a tracked vehicle, but can not do both).

One example of such a prior art approach combined a standard tracked ROVwith a third-party auger dredge (see, for example, “Robotic Removal ofZebra Mussel Accumulations in a Nuclear Power Plant Screenhouse”, Kotieret al, February 1995). The objective was to search out Zebra Musselcolonies and remove them by auger dredge and pipe the debris to thesurface. The apparatus had numerous disadvantages and limitations. Itrelied upon divers for inspection, having no other means to manuallylocate and map colonies of Zebra Mussels. The tracked vehicle wasrestricted to operation on flat and level surfaces. Debris removal wasnot scalable, being restricted to a single auger head. It lacked otherthan visual inspection and guidance (via either human or closed circuitcamera) and had no means to control turbidity generated by the augerdredge, which resulted in blind operation. An operator, faced with poorvisibility, would fail to locate the mussel colonies or even drive theROV off course and roll it over. The apparatus further lacked automatedmeans to manage the debris hose after it reached the surface so thatdebris removal and disposal rates could not be continuously coordinated.

A more promising prior art approach was the creation of a specialpurpose ROV (see, for example, Spurlock, et. al., U.S. Pat. No.4,763,376) that integrated its work process tools into its frame. TheMaintenance, Inspection, Submersible Transport (“MIST” hereinafter)utilized an umbilical to provide electricity from the surface as themeans to achieve sufficient power to effectively remove and processdebris in large submerged conduits. Electricity was converted tohydraulic fluid pressure to power the hydraulic actuators in variouscomponents.

Adjustable legs and arms could address varying diameters of conduit. Adrive wheel, mounted on the outboard-end of a pivoting strut, wasutilized to provide traction against the surface of the conduit.Cleaning was accomplished via extendable and rotating cleaning strutsfitted with four spinning mechanical scrapers. A debrisprocessing unitscooped up loosened debris, pulverized it, and ejected it away from thedevice.

Although designed for semi-automatic and remote operation, the MISTrequired a diver to operate it and to perform its intended function. Acage-like frame accommodated a dive chamber for transporting the diveralong with the ROV.

Despite its promise over prior art, the MIST (and any similar prior art)still suffered significant limitations and disadvantages: Inspection waslimited a operator/diver requirement. Navigation was limited by a fixed,non-articulating frame. Scalability was limited by a fixed andnon-expandable configuration. Optimization was limited by conflictingrequirements: a diver and deadly high-voltage current in closeproximity. Performance was limited by reliance on manual inspection,navigation and optimization, and an inadequate debris recovery system.

Fully automated methods do not require diver involvement but are limitedin the types of tasks or environments in which they can perform. Forexample, the prior art may disclose an apparatus with the ability toperform some level of inspection in an automated fashion, but the sameapparatus cannot perform remediation. Similar inflexibility manifests inmost of the prior art. This limitation is caused by automated apparatusarchitecture that is of a monolithic nature and lacking standardized orinterchangeable parts. Alternatively, the prior art may disclose anapparatus with the ability to remediate a round, small diametersubmerged conduit, but is unable to negotiate obstacles. In all of thesecases, divers must be used to compensate for these and numerous otherdisadvantages and limitations of the prior art apparatus.

The automated ROV (see, for example, Rodocker et. al., U.S. Patent Pub.No. 2007/0276552 A1) incorporates sensors able to perform inspection.The resultant data is compared to pre-determined thresholds and, shoulda threshold level be exceeded, an appropriate pre-programmed reaction istriggered. Despite various advances applied to inspection and navigationproblems, automated ROVs suffer the same limitations and disadvantagesof Manually operated ROVs.

Control systems for fully automated apparatus, including various typesof autonomous or robotic vehicles, are well known in the prior art, buthave seen only limited application to systems for infrastructureremediation. In most cases, they have been applied to apparatus having afixed mechanical configuration and requiring reengineering whenever thatconfiguration was changed.

U.S. Pat. No. 7,720,570 B2 (Close, et. al.) teaches “Plug-and-Play”attachment of a variety of tool heads and sensors to the frame of arobotic device for subterranean infrastructure rehabilitation. This isaccomplished via a “universal interface” (a.k.a. “tool head interface”)for standardized connection of interchangeable tool heads or sensors tothe device body, and that is movable with respect to the device body.Tool heads and sensors attached via the universal interface are“self-describing” with respect to functionality. The patent fails todisclose how the mechanical aspect of the interface is accomplishedbeyond including a “power take-off”, flexibility, and quick connectcapability, and does not teach any method for integrating power andcommunication interconnection into a single bus. Means for accomplishingcomponent self-discovery, self-recognition, and self-configuration uponconnection to a network connected to the control system are disclosed,and these determine functional options presented to an operator on acomputer display. Means for locating the robot's position(“localization”) are described, including the use of markers detectableby the robot. Movement of a tool head is limited to three degrees of therobot body and three degrees of freedom of the tool head with respect tothe robot body. No methods are disclosed for controlled articulation(i.e., movement of multiple parts in different ways at the same time) ofa tool head, let alone flexible configuration of a tool head or otherattachment to the robot. Although multiple tool heads attached to onerobot are disclosed, no means of coordinating the activities of thosetool heads is disclosed.

U.S. Pat. No. 6,108,597 (Kirchner et. al.) discloses the use of aplanning system for robot navigation, including sensor-based andmap-based path planning. An autonomous mobile robot system is providedwith a sensor-based and map-based navigation system for navigating apipe network, taking into account sensor inaccuracy and motioninaccuracy (e.g., due to drift, slip, and overshoot). The system usesposition sensing, including recognition of natural landmarks andartificially placed markers, to determine a “plausible position” withrespect to a map. A path plan is then developed to reach a goal from theplausible position.

U.S. Pat. No. 7,555,363 B2 (Augenbraun) discloses a multi-functionrobotic device selectively configurable to perform a desired function inaccordance with the capabilities of a selectively removable functionalcartridge operably coupled with a robot body. Mechanical characteristicsof the functional cartridge are determined automatically. Localizationand mapping techniques may employ partial maps associated with portionsof an operating environment, data compression, or both. Means to avoidan obstacle are disclosed.

U.S. Pat. No. 6,917,176 B2 (Schempf, et. al.) discloses a gas maininspection system having multiple modules connected in a train, andjoint members for interconnecting adjacent modules where the jointmembers enable articulation of modules in multiple planes and multipleangles with respect to each other.

U.S. Pat. No. 5,548,516 (Gudat, et. al.) discloses a system forpositioning and navigating an autonomous land-based vehicle. It teachesmeans for using a scanning system for obstacle detection, a positioningsystem to determine vehicle location, and a tracker system to calculatesteering and speed corrections.

U.S. Patent Pub. No. 2010/0292835 A1 (Sugiura, et. al.) discloses meansfor using a planning module, target input interface, a predictingmodule, and a reactive controller for autonomous robot planning in adynamic, complex, and unpredictable environments.

U.S. Patent Pub. No. 2009/0234527 A1 (Ichinose, et. al.) discloses anautonomous mobile robot device and teaches means for obstacle detectionand path planning for reaching a goal while avoiding the obstacle usingvarious pre-determined avoidance methods.

U.S. Patent Pub. No. 2003/0171846 A1 (Murray, et. al.) discloses methodsand apparatus for a hardware abstraction layer for a robot such that theunderlying robotic hardware is transparent to perception and controlsoftware (i.e., robot control software).

U.S. Patent Pub. No. 2002/0016649 A1 (Jones) discloses a robot obstacledetection system using optical emitters and sensors.

U.S. Patent Pub. No. 2003/0089267 A1 (Ghorbel, et. al.) discloses anautonomous robot crawler for small-diameter enclosed pipes or conduits.

U.S. Patent Pub. No. 2004/0013295 A1 (Sabe, et. al.) discloses anobstacle recognition apparatus and method, including software system fora robot that moves along a floor (planar surface). It is capable ofdetermining the position of the obstacle. U.S. Patent Pub. No.2009/0292393 (Casey, et. al.) and 2010/0275405 (Morse, et. al.) disclosesimilar systems for obstacle detection and obstacle avoidance orobstacle following.

U.S. Patent Pub. No. 2005/0145018 A1 (Sabata, et. al.) discloses meansto use a wireless sensor network to monitor pipelines.

U.S. Patent Pub. No. 2008/0147691 A1 (Peters) discloses an architectureby which a robot may learn and create new behaviors in a changingenvironment using sensory input.

U.S. Pat. No. 6,162,171 (Ng, et. al.) discloses a multi-segmentautonomous pipe robot frame with articulated joints between thesegments.

U.S. Patent Pub. No. 2009/0276094 A1 (DeGuzman, et. al.) discloses anautonomous robot that performs maintenance and repair activities in oiland gas wells, and in pipelines. It uses well and pipeline fluids forlocomotion, and sensors, maps, plans, knowledge base, and patternrecognition to plan and achieve goals.

U.S. Patent Pub. No. 2010/0063628 A1 (Landry, et. al.) disclosesapparatus and methods for obstacle following (i.e., movement along anobstacle) by a robotic device using a combination of deterministic pathdetermination (i.e., navigation according to a plan) and path by randommotion. A sensor system comprising a bump sensor, a debris sensor, andan obstacle following sensor is disclosed.

U.S. Patent Pub. No. 2010/0274430 A1 (Dolgov, et. al.) discloses amethod for semiautonomous navigation comprising creating an obstaclefree diagram using topological sensor data about a surface.

U.S. Patent Pub. No. 2010/0286827 A1 (Franzius, et. al.) discloses arobot with a method for processing signals from a video or still cameraso as to recognize three dimensional shapes and their properties.

While the foregoing prior art discloses various elements used in thepresent invention, none apply the combination to achieve the synergism,functionality, and benefits of the present invention.

All prior art apparatus and methods for infrastructure remediation,including but not limited to those discussed above, fail to address oneor more of the INSOP infrastructure remediation solution requirements,and therefore fail to achieve the advantages and synergy of meeting allof those requirements. Prior art apparatus and methods all have a needfor reliance upon manual methods that include divers and surface supportcrews. These include, but are not limited to, the following, and theirnumerous combinations, variations, and extensions: divers and theirimplements; pipeline pigs; specialized apparatus, whether towed, orself-propelled, whether utilizing mechanical means or pressurized water,and whether operating individually or as the central component of asystem of supporting facilities; specialized apparatus, whether towed,or self-propelled, whether utilizing mechanical means or pressurizedwater, and whether operating individually or as the central component ofa system of supporting facilities; and, ROV's, whether generalized,special purpose, manual or automated.

SUMMARY OF THE INVENTION

An apparatus and method are disclosed whereby a plurality of modularcomponents (typically modules and tools), each having a set of functionsand capabilities, may be rapidly configured and/or reconfigured so as tofunction cooperatively, creating a configurable robotic assemblage.Preferably, each modular component incorporates at least onestandardized connector capable of mating with any other standardizedconnector in an interchangeable manner and used to convey mechanicalstability, power, and signals between modular components. Each modularcomponent incorporates a processor and data storage for storing themodular component's identity, status, and programmable functionality,and for responding to commands. Storage may be reprogrammed while therobot is operational, altering both the set of commands andcorresponding command responses. More sophisticated software functionsmay be provided. After interconnection via standardized connectors,inter-module power and communication are established and each modularcomponent identifies itself and its functionality, thereby providing“plug and play” configuration.

The present invention comprises an apparatus incorporating a particularsystem and methods that effects the remediation of submerged orsubterranean infrastructure. The principal apparatus is the SubmersibleRobotically Operable Vehicle (“SROV” hereafter). The SROV providesinnumerable user-defined configuration possibilities through its highlyflexible and versatile modular architecture that leverages standardizedand interchangeable sub-parts. The SROV's Module Intelligence andInstrumentation (‘MII’) provides the basis for a functional automaticitythat can be subordinated to manual, i.e. human override to effectnon-anticipated but necessary guidance and control. Supportingapparatus, facilities, and software methods for the SROV are furtherdetailed below. As used herein, the terms “proximal” and “distal” areassumed to convey orientation relative to connectivity with theOperations Center (OC—see below) for definiteness of description,although alternative orientations will be obvious to those of ordinaryskill in the engineering arts.

This novel and non-obvious modular robotic architecture is an extensionto, and unique integration of prior art. Diverse underlying technologiesinclude, but are not limited to, those pertaining to robotics,automation, computer-based modeling, hydraulic and electrical controlsystems, submersible vehicles, and underwater marine construction. Theresult is a more realistic, flexible, lower risk, environmentallyresponsible, safer, and more cost-effective apparatus, system, andmethod that resolves the disadvantages and limitations of the prior artfor the general problem of submersed surface inspection, maintenance anddebris removal.

In a general sense, the prior art has involved a dichotomous choice:either human operation was required (whether immediately present orremote) or absent. The SROV shifts this to a range of human involvementwhere the extent of human operation can be changed during the SROV'sdeployment to any state from completely absent to remote to ‘immediatelypresent’ and in control through the MIT. A human can, but need notnecessarily, operate the SROV—meaning the most mind-numbing, repetitive,and fullyunderstood conditions can be left to the witless but persistentattention of the machine, unless or until an interrupt or human-orderedinterruption occurs.

SROV automation capabilities allow it to overcome numerous limitationsand disadvantages of prior art, ranging from the manual efforts ofdivers to the overspecialized and unaware automation of the remotelyoperated vehicle. A remotely operated vehicle still requires bothconstant and detailed control by a remote operator, as well the manualwork process assistance of divers and surface attendants. The presentSROV resolves the prior art limitation of remote operator guidancethrough automatic detection and programmed response to anticipated workrequirements and conditions, while retaining the ultimate flexibilityand adaptively by allowing human operator guidance and control whenalerts concerning any unanticipated, exceptional, or interferingproblems arise. The SROV resolves the prior art limitation of thenecessity for manual work process assistance by meeting all INSOPrequirements, and being fully automated, yields high-performanceproduction across a wide spectrum of work processes.

Until the disclosure of the present invention, prior art limitations inaddressing cost, efficiency and safety metrics had restrictedremediation to a function of periodic maintenance—often unplanned,deferred, and ultimately, mandatory at a great cost. By leveragingautomation, the present invention is able to fit into the limited timeand budget allocations available for routine plant maintenance programs.In resolving prior art limitations, the present invention transitionsremediation from periodic to routine maintenance. The present inventionmakes it possible for industry and government to afford routinesubmerged infrastructure remediation, and potentially realize billionsof dollars in operations savings.

This summary of the invention is described by way of one illustrativeembodiment (unless noted otherwise), and nothing in this section isintended to be limiting. The SROV (FIG. 2) comprises the following majorsubsystems: (1) an SROV (220); (2) a Mobilization Platform (“MP”) (211);and, (3) an Operations Center (230). The latter two are non-SROVfacilities and considered SROV Supporting Equipment (see below for moredetail).

The SROV comprises a plurality of modular components (e.g., modules andassemblies) designed to facilitate field assembly and configuration asdesirable and suitable to the anticipated and, later on, experiencedconditions. Certain standard modules are anticipated and described indetail below (see “SROV Module Types”). Any SROV can be re-configuredmid-job to cope with a partial breakdown, an unanticipated obstacle, ora task-change. Power and communications are transferred among thesemodular components via a standardized bus that is incorporated in eachmodular component. Mechanical, power, and communications connections areeffected and mediated by standardized connectors that provide auniversal interface. Modules have a common architecture as describedmore fully below, especially under the section entitled “SROV ModuleArchitecture”. Modules and major assemblies have on-board intelligence(e.g., a computer or processor and software) that provides functionalcontrol, programmability, automated self-identification (includingfunctionality) on being connected, and collection of data from sensorsthat instrument the module and/or major assembly. This aspect of theinvention is described in more detail below, especially under thesection entitled “Module Intelligence and Instrumentation”. Theresulting modules and assemblies are typically interchangeable (see“Standardized Module Interconnectivity” below for more detail); have adegree of task-specifiable, autonomous articulation and functionality;and offer “plug-and-play” configuration in the field.

A distributed, multi-level control system provides coordination of andfeedback across modules, major assemblies, and components, and the SROV,as well as monitoring (see “Distributed Control System” below fordetails). The SROV can be configured in the field for a targetenvironment. It can be programmed to navigate the submergedinfrastructure, perform a remediation work process (includinginspection, maintenance, and debris recovery), detect and avoidobstacles or deviations, and extract itself In many cases, the foregoingactivities can be achieved in a fully automatic manner (i.e.,autonomously), thus limiting or eliminating the need for continuoushuman supervision, operation and control.

FIG. 3 provides an overview of one illustrative embodiment of the SROV.Starting from the left side and the end furthest from the Umbilical(385) and Debris Line (387), which connect to the MP and OC, the SROVwill progress through a conduit leading with a pair of Shoulder Modules(1400) that can bi-directionally rotate around the conduit'slongitudinal axis. From each Shoulder Module extends a plurality ofArticulation Modules (1500) fitted with Debris Removal Tools (1600),each capable of a multiplicity of motions for removing debris on theinterior surface of the conduit. Next, is an assembly comprising aShoulder Module and Articulation Module, fitted with Track Tools (350)and provides work platform stability for the front of the SROV andpropulsion for axial transit. Immediately behind this front drivesub-unit is the SROV Frame Module (1300), containing power and controlequipment. Each end of the Frame Module preferably contains at least oneMulti-Axis Joint (1350) to enable the SROV to manage bends and twists inthe conduit by a flex (e.g., a bend of up to 90 degrees away from thelongitudinal axis) or a twist (e.g., a rotation of up to 360 degrees inthe plane parallel to the longitudinal axis). Following the Frame Moduleis an assembly comprising a Shoulder Module and an Articulation Moduleconnecting a Debris Recovery Tool (1700). Next, supporting the rear ofthe SROV is a second Shoulder and Articulation Module assembly (371)that is fitted with Track Tools and both propulsion for axial transitand stably positioning the Frame module with respect to a work surface.At the rightmost side of the drawing is the end of the SROV with thePower Management Unit (381), Umbilical Connector (383), and Umbilical(385) that links the SROV to the MP.

The MP is a non-SROV facility used to manage the Umbilical and theDebris Line. The Umbilical supplies power to the SROV and communication(i.e. both sensing and control signals) between the SROV and systemsexternal to the SROV. The Debris Line carries debris pumped from theSROV to a Debris Reclamation Interface.

The OC, including the Central Control Unit (‘CCU’), is used to plan,manage, and override autonomous SROV activities, provide means foroperator-initiated control, and to monitor, respond to, present,display, record, and analyze status signals from the SROV or SROVs. Itis interconnected to each SROV via that unit's MP and Umbilical.

The Submersible Robotically Operated Vehicle, leverages modularity,instrumentation, and distributed intelligence to resolve the limitationsand disadvantages of the prior art. The SROV and its supporting systemsprovide an end-to-end automation suite to meet INSOP requirements, whileavoiding the requirement for excessive manual intervention:

Inspection limitations of prior art range from the lack of anycapability, to a restriction to visual means, or the capability ofsimultaneous video and sensor recordings for later laboratory analysis.The SROV resolves these limitations (FIG. 6) in its ability to conduct,integrate and model a simultaneous multiplicity of sensorbasedtechniques. A collection of sensors can effectively form an envelopearound the SROV (660 and 670), enabling the operator to be presentedwith a multi-faceted view and understanding of the “before and after” ofwork processes performance. This includes a detailed analysis ofremediation performance, and resultant surface and subsurfaceconditions. Any new sensor can be added with the sensor's designer onlyhaving to create the interface between the sensor's inputs and thestandardized outputs (visual, aural, haptic) of the SROV, MP and OC.Instead of having to write everything from the ‘driver’ to the ‘GUI’,the SROV provides the GUI and API for any application developer.

Navigation limitations of prior art include a restriction to visualmeans, only having rudimentary pre-programmed or real time guidance, anda lack of flexibility to avoid obstacles. The SROV resolve theselimitations in its ability to incorporate sensing instrumentation,intelligent planning, and pre-programmed knowledge of the work area, andhaving the articulating flexibility (1351) to allow the SROV toautonomously negotiate a wide variety of slopes or curves (FIG. 7). TheSROV is able to utilize its sensors and obstacle avoiding or obstaclefollowing programs to be able to negotiate a changing environment (FIG.8) including the ability to retract its Extensible Arm Unit (1500) or tobe able to angle its Wrist Unit (1520) in order to position Tools incontour with changing surface angles or conditions.

Scalability limitations of the prior art include restrictions on thetype and level of functionality in a work process. The SROV resolvesthese limitations by combining a highly modular and reconfigurabledesign with automated sensing, response, and control. It can flexiblyincorporate and integrate multiple types of functionality (includinginspection, maintenance and repair) and is able to increase reach,range, and production levels as required to adequately service variousinfrastructure sizes, geometries, and irregularities (FIG. 10A, FIG.10B, FIG. 10C, FIG. 10D, FIG. 10E).

Optimization limitations of prior art include restricted coordination ofmultiple work processes. The SROV resolves these limitations byinstrumenting the articulation of its components (e.g., modules),allowing it to coordinate multiple work activities. For example, theSROV may be constantly centered on the axis of the conduit, whilesimultaneously matching the rates of axial transit, debris removal, anddebris recovery as work conditions vary.

Performance limitations of prior art include restrictions on the abilityto automate work processes. The SROV resolves these limitations byautomating and coordinating any operation that may be implemented viaarticulating and coordinated attachments. SROV performance manifests byreduced reliance on manual intervention. To increase performance whilemaintaining a “one pass” completion of remediation, and to reducerequired plant downtime, additional modules (FIG. 9) may be added suchas an additional Shoulder Module (1400) supporting a second DebrisRecovery Tool (1700), and where a “Y” fitting connects the first andsecond Debris Recovery Tool into a larger diameter Debris Line (930) toaccommodate the additional debris processing.

BRIEF DESCRIPTION OF THE DRAWINGS

The following is a brief description of the drawings, which are notnecessarily drawn to scale.

FIG. 1 A is a diagrammatic view of a diver-operated spray cleaneraccording to the prior art.

FIG. 1B is a partial sectional view of a pig according to the prior art.

FIG. 1C shows a remote operated submersible vehicle according to theprior art.

FIG. 2 is a diagrammatic perspective view of an SROV system according tothe invention, in which the system is being used to remediate coolingwater conduits in a Power Plant.

FIG. 3 is a diagrammatic perspective view of an illustrative embodimentof an SROV according to the invention.

FIG. 4A is a partially exploded, perspective view of an articulationmodule.

FIG. 4B is a partial, perspective view of the articulation module shownin FIG. 4A in a retracted (solid) and extended (phantom) position.

FIG. 4C is a partial, perspective view of the articulation module shownin FIG. 4A with a track tool in a deployed position.

FIG. 5A is a front side view of an articulation module, a hand module,and a tool before being leveled.

FIG. 5B is a front side view of the articulation module, the handmodule, and the tool after being leveled.

FIG. 6 is a perspective view of an SROV according to the invention withsensor-based inspection capability.

FIG. 7 is a side view of the SROV while autonomously navigating a curvedupslope.

FIG. 8 is a side view of the SROV autonomously navigating a narrowingconduit.

FIG. 9 is a side view of the SROV operating with an additional debrisrecovery module.

FIG. 10A is a front side view of the SROV in a narrow, circular-crosssection conduit.

FIG. 10B is a front side view of the SROV in a wide, circular-crosssection conduit.

FIG. 10C is a front side view of the SROV in a rectangular-cross sectionconduit.

FIG. 10D is a front side view of the SROV operating around acircular-cross section conduit.

FIG. 10E is a front side view of the SROV working on a flat surface.

FIG. 11A is a sectional view of a bus according to the invention.

FIG. 11B is an exploded, perspective view of a universal connectoraccording to the invention and including the bus shown in FIG. 11A.

FIG. 11C is a perspective view of the universal connector shown in FIG.11B.

FIG. 12A shows side view of a joint assembly.

FIG. 12B is a perspective view of a joint assembly.

FIG. 12C shows a detail of one embodiment of the joint assembly.

FIG. 13 is a perspective view of a frame module.

FIG. 14 is a perspective view of a shoulder module.

FIG. 15A is a perspective view of an articulation module that is anelbow unit.

FIG. 15B is a side view of an articulation module that is a wrist unit.

FIG. 15C is a perspective view of an articulation module that is a fixedarm unit.

FIG. 15D is a perspective view of an articulation module that is anextensible arm unit.

FIG. 16 is a perspective view and a side view of a debris removal tool.

FIG. 17 is a perspective view of a debris recovery tool.

FIG. 18 is a block diagram of a distributed control system according tothe invention.

FIG. 19 shows a block diagram of functional software architecture ofmajor software subsystems of the distributed control system andrepresentative control flows and data flows.

FIG. 20 is a block diagram showing a distributed and networked computersystem upon which the distributed control system may be deployed.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

It is to be understood that the figures and descriptions of the presentinvention have been simplified to illustrate elements that are relevantfor a clear understanding of the invention, while eliminating, forpurposes of clarity, other elements that may be well known. Those ofordinary skill in the art will recognize that other elements aredesirable and/or required in order to implement the present invention.However, because such elements are well known in the art, and becausethey do not facilitate a better understanding of the present invention,a discussion of such elements is not provided herein. The detaileddescription will be provided herein below with reference to the attacheddrawings.

The Submersible Robotically Operated Vehicle is a unique and novel,unobvious integration of, and refinement to the prior art. The SROV hastransformed the remotely operated vehicle into the robotically operablevehicle. A remotely operated vehicle requires both the participation ofa remote operator, as well as divers and surface attendants. Arobotically operable vehicle incorporates an end-to-end automation suitethat dramatically reduces the need for human intervention yet leaves thepotential for conscious and intelligent human control open at alllevels.

The preferred embodiment (FIG. 2) is comprised of the following majorsubsystems: (1) an SROV (220); (2) a MP (211); and, (3) an OC (230). TheMP (211) is a non-SROV facility used to manage the Umbilical and theDebris Line. The Umbilical supplies both power to the SROV andcommunication (i.e. both sensing and control signals) between the SROVand other subsystems. The Umbilical Supply Reel (214) manages the payingout and recovery of the Umbilical in unison with the travel of the SROV.The Debris Line (213) carries debris pumped from the SROV. An overheadcrane (215) is utilized to insert or remove sections of debris line hose(216) as to synchronize Debris Line length with that of the Umbilical.The Debris Line terminates into the Debris Reclamation Interface (219)allowing for proper debris disposal. The OC (230), including the CCU, isused to plan and manage autonomous performance by the SROV of tasks,activities, and goals; provide operator-initiated control; and tomonitor, present, display, record, analyze, and respond to statussignals from the SROV.

The SROV (FIG. 3) comprises a number of standardized assemblies andmodules, described below. SROV modules share certain common components,common means for connecting to other modules, and a degree of commonconstruction. The latter includes materials selection for frame and bodycomponents and could range from an appropriate composite material, oralternatively, anodized marine grade aluminum, or even a marine grade ofstainless steel. These and other selections of material or detailedconstruction are irrelevant to their novel application.

Each assembly and module capable of articulation uses actuators tocontrol power and movement, and sensors to monitor a plurality ofconditions—which in combination effect the instrumented articulation forthe SROV at each of the separable levels of module, sub-unit, andSROV-as-a-whole. For any subset of module, instrumentation, actuators,and sensors—one or more modules or sub-modules, for the SROV as awhole—these actuators and sensors may be controlled and monitored withinthe SROV (e.g., autonomous control), or remotely (e.g., remote control).

The SROV modular architecture incorporates and integrates (1)technologies common to modules, (2) capabilities specific to aparticular module, and (3) configurability that aggregates thecapabilities of multiple modules. This physical modular architecture isparalleled with internal computer architecture. Encapsulation at afunctional level enables implementation details and current sensoryfeedback to be pushed down to the most appropriate and most readilycorrelated and correctable level. Problems within a particular moduleare separate from overall SROV operation, allowing replacement to bemanaged with a least level of effort. Online, autonomous“track-and-swap” capability, allows for repair without requiring theentire SROV to be removed from service.

In the preferred embodiment, sensors are embedded into all modules totrack external (e.g., temperature, pressure, electrical conductivity,chemical toxicity levels) and internal (e.g., connectivity, stress,accelerations) conditions. Each module is capable of ‘self-awareness’that can be communicated beyond the scope of an internalized model ofthe environment, but as experience in real-time.

These actuators and sensors are linked both within the module and to theMP and OC, enabling both local ‘reflexes’ and remote ‘intelligent,conscious control’. For purpose of the preferred embodiment, eachcombination of OC, MP, and SROV modules function as an integrated whole,spanning operations capacity ranging from the fully automated to fullyunder human control.

SROV components (e.g., the modules, tools, and assemblies describedherein) are easily interconnected in numerous configurations so as toprovide a wide range of functionality. This is accomplished bystandardizing the mechanics and method of module interconnectivity.Standardized Module Interconnectivity comprises both (1) a mechanicalmeans for hardware interconnection of, and transfer of physicalresources between, modules, and (2) a signaling means for softwareinterconnection of and transfer of informational resources betweenmodules.

The mechanical inter-module connection means provides support forphysical module connection and for the physical interconnection of theBus, which is the conduit of resources between modules, and is mediatedby standardized interfaces. Preferably, the mechanical means serves thedual purpose of a physically stable connection of modules and aprotective shield around the Bus where it interconnects to transfer BusResources between and across modules. The Bus comprises a standardizedset of power conductors (i.e., means for conveying power) andcommunications conductors (i.e., means for conveying signals) forconveyance of Bus Resources between modules and subsystems. BusResources include, without limitation, signals and power (e.g.,hydraulic, electrical, pneumatic, mechanical, etc.). Signals may share acommon networked conductor (e.g., by multiplexing) and the number andtype of power conductors are standardized (and preferably minimized)throughout an SROV (including the modules, tools and assemblies). Thisapproach resolves a prior art limitation, where the mating of conductorsdepends upon the number and function of conductors, or the type ofmodules being interconnected, and greatly limits configurationflexibility.

A single, standardized design for each of (a) a SROV power andcommunication bus (“Bus” hereafter) being divided into a plurality ofbus segments, (b) a connector, the SROV Plug (“Plug” or “Plugs”hereafter), and (c) a mating connector, the SROV Socket (“Socket” or“Sockets” hereafter), to provide a standard method for physicalinterconnect of Bus segments running between modules, assemblies, andsubsystems. The architecture of the Bus, as shown in FIG. 11A, includesprimary hydraulic supply and return lines (1123), auxiliary hydraulicsupply and return lines (1124), electric power conductors (1125), andcommunication conductors (1127). Other or additional connectors,conductors, or alternative means of conveyance may be used in thisembodiment.

The hardware interconnection of SROV modules, as shown in FIG. 11B andFIG. 11C, utilizes Plug (1130) and Socket (1131) for simultaneous andtransparent hardware interconnect, and to pass the Bus Resources via theBus (1110) between modules. In this embodiment, a Plug or Socketencapsulates the connectors of the individual conductors of the Bus andpasses the Bus between modules by providing connection, seating, andseal (e.g., against pressure, leakage, corrosion, etc.). In someenvironments, the Plugs and Sockets may be of the “quick connect” and“quick disconnect” variety (well known in the prior art), furtherimproving the ease with which SROV configurations may be effected.

Plug and Socket bodies are machined from non-corrosive metal such asmarine grade stainless steel or cast from a high-strength, compositematerial. For each type of individual bus conductor, a proper seating,and seal (e.g., against pressure, leakage, corrosion, etc.) is provided.The contours of the interlocking nesting between plug and socket createareas for environmental seal by machine fit, incorporation of o-rings,or other approaches well known in the art.

The hardware interconnection architecture, also shown in FIG. 11B andFIG. 11C, includes a pair of Adapters, corresponding to the interlockingprofile of the Plug and Socket and having the requisite mechanicalstructural integrity for cross module interconnection. A plurality ofAdapter diameters is incorporated as to accommodate differing diametersof SROV Modules and includes: (1) A Large Plug Adapter (1132) and aLarge Socket Adapter (1133), used to provide mechanical connection forthe larger modules (e.g., Frame Module and Shoulder Module); (2) A SmallPlug Adapter and a Small Socket Adapter (not shown), used to providemechanical connection for smaller modules (e.g., the Units of theArticulation and the Hand Module); and, (3) An Auxiliary Plug Adapterand Auxiliary Socket Adapter (not shown), used to terminate an Umbilicalversion of the SROV Bus into a flush mount socket. For the purposes ofdescribing this embodiment, when the term Plug or Socket are used below,in reference to a module or sub-module, the incorporation of the propercorresponding Adapter is to be included by above reference.

An Adapter provides for insertion of a Plug or Socket connector througha receptacle area milled from the center of the Adapter. A lip on theface of this cutout conforms to a reveal in the face of the connectorsso as to provide a stop for the insertion. The contours of theinterlocking nesting between the connector and the Adapter provideadditional areas for environmental seal by machine fit, incorporation ofo-rings, or other approaches well known in the art.

To assure proper connection, insertion and orientation, a plurality ofalignment mechanisms, such as a notch that corresponds to a groove, areincorporated in the following areas: (1) On a Plug face andcorresponding Socket face to assure proper connection; (2) On an outerbody of Plug or Socket and corresponding interior of an Adapter cutoutto assure proper insertion; and, (3) On an Adapter face andcorresponding mating Adapter face to assure proper orientation.Mechanical fasteners affix the Plug or Socket into the correspondingAdapter. Additional mechanical fasteners secure the Adapter, through aplurality of mounting holes located around both edges of the flangeperimeter, allowing one side to be bolted to the module, and the otherto its mating Adapter.

The software interconnection or communication portion of the Busprovides network connectivity, preferably over a fiber optic cable asthe conductor. Signals include, for example, control signals and sensorsignals. Control signals convey commands to actuators and sensors.Sensor signals convey, for example, operational information such asstatus, location, motion, Solution Pattern currently being executed orscheduled, function, damage, history, and current model, andenvironmental information such as temperature, pressure, andconductivity. Each module contains local intelligence in the form of aModule Control Unit (“MCU” hereafter) (described below) so that themodule selectively accepts only those control signals intended for it,and executes only relevant commands. This means, for example, that amodule need respond only to module-specific safety constraints(inter-module physical interference or co-positioning efforts will beignorable by other modules in the SROV unless or until control and tasksof the SROV as a whole, as opposed to the directly contacting modules,are involved. Other localizable subordinate interactions can be embeddedsuch as loss-of-connection responses, blockage or wear warnings, orsimilar ‘local reflexes’. Actuators and sensors within a module areconnected to the portion of the Bus used for communication signals viathe MCU in that module. The MCU responds to commands, locally collectsand interprets sensor signals (including feedback of positioning,movement and other results such as module or environmentalmeasurements), and activates or deactivates actuators. This designprovides the mechanisms and information necessary for a complete,closedloop automation feedback cycle. Preferably, signals are formattedusing a standard language for command, control, and sensing, asdiscussed in more detail below.

Configuration ease and flexibility is achieved by the standardizedconnections between modules and the ability of MCUs within modules to beinterconnected (both mechanically and with respect to Bus Resources) andto communicate, and identify themselves to other MCUs. The Master ModuleControl Unit (“MMCU” hereafter) and the CCU (described below), withoutmechanical or software re-engineering—interpret, aggregateconfiguration, and provide monitoring, control, and functionality of anSROV body and attachments resulting from interconnection. Any of themodules described herein may be interconnected with “plug-and-play”simplicity, thereby enabling the SROV with the functionality necessaryfor a wide range of work processes and environments. Integrating tactileor ‘haptic’ sensors at any level of module enable realtime, real-worldcoordination between operating model and real world conditions of bothenvironment and that module itself. Field operations personnel caneasily configure SROV modules (described above) and in support of anunlimited array of work processes and environments. This includes theautomated remediation for any of the following: interior infrastructuresurfaces as characterized by size, geometry, and irregularities (e.g.,curves, slopes, angles, or protrusions); exterior infrastructuresurfaces; a variety of types and amounts of fouling; and, specializedtasks by easily integrating third-party or custom tools.

Each module of the SROV incorporates both on-board or module-specificintelligence and instrumentation (the ‘MEP’ first referenced above) thatare interfaced to the communication portion of the Bus. Preferably theon-board intelligence is a programmable computer having at least amemory unit, a processing logic unit, a stored program for the modulesuited to the processing logic unit, and an 110 unit or on-board sensorand instrumentation. Input is taken regarding the module's externalenvironment and internal status, and output is produced regarding motionor current status for the module. On-board intelligence ispre-programmed to control the detailed functionality of the moduleresponsive to external signals (both control and sensory) and to collectand aggregate data from the instrumentation. This provides each modulewith a degree of articulation and the means for the control andmonitoring of that articulation as well as the monitoring of theresultant effect upon the experienced environment. Thus a Track Toolcould have intelligence and sensors focusing on position, location,energy usage, internal temperature, drive tread motion, and pressure;while a Debris Removal Tool might have intelligence and sensors focusingon spin, resistance, temperatures, pressure, and surface conductivity.

An interruptable but closeable loop feedback and control system iscreated by the instrumentation of SROV motion, the observation of SROVlocation or other operations within the external environment. Feedbackcollectively includes signals or information from any output device, oractuator; any sensor for the external environment; any sensor for theinternal status; any on-board logic-processing and memory units or anyembedded program. These may be monitored and controllable throughautomated, automatable, or manual efforts at the MP or even the OCproviding the feedback link for an interruptable but closeable loopfeedback and control system.

Control signals, received by the module over the Bus are filtered todetermine if they should be implemented within the module. Signals aretransformed, according to Control Templates, from generic commands(e.g., for positioning and movement) into the detailed commandsnecessary to achieve the desired result using the actuators within thatparticular module. Sensors respond with feedback of positioning,movement and other environmental results to provide a complete,closed-loop, automation feedback cycle, and as more fully described inthe Distributed Control section below.

Mechanical motion of a module is generated and governed through a set ofstandardized actuators, joint assemblies, and sensors. This includescontrol of the mechanical movements required of the actuators, as wellas the monitoring and feedback of the results and impact of theactuation. Standard joint assemblies include but are not limited to: (1)A Sliding Joint Assembly (FIG. 12A) is incorporated into theArticulation Module as well as various Tools to provide means forcontrollable inline motion or extension; (2) A Rotary Joint Assembly(FIG. 12B) is incorporated into the Shoulder Module, as well as variousTools, to provide controllable rotation capability; and, (3) AMulti-Axis Joint Assembly (FIG. 12C) is incorporated into the FrameModule and Wrist Unit, as well as various Tools to provide controllablemulti-axis articulation and rotary positioning (i.e., radialorientation). Not excluding other potential embodiments, the Multi-AxisJoint Assembly consists of a plurality of Rotary Joint Assemblies andwhere one set is positioned perpendicular to the longitudinal axis ofthe joint (1240, 1244, and 1248), while another set is positioned at anoffset angle (e.g., twenty-two and one half degrees) (1242 and 1246) inthis embodiment. As additional Rotary Joint Assemblies are added, theoverall possible angle of the articulation for the joint increases. Thisabove approach provides an accurate radial and rotary positioning whileproviding an exoskeleton for internal routing of and protection of theBus.

Each individual joint assembly utilizes standardized parts andcomprises: (1) a Drive Sub-Assembly (1210 and 1232) to create the properarticulation; (2) a Bus SubAssembly (1220 and 1230) to route the busacross the mechanical connection; and (3) a Control Sub-Assembly (notshown) to operate the actuators and monitor the sensors as tointelligently instrument its articulation and enable current-statusfeedback and control. The Drive Sub-Assembly consists of a MechanicalCoupler, Drive Mechanism, and Hydraulic Actuator.

The Mechanical Coupler enables the desired articulation (e.g.,differential, inline, linear, radial, or rotary) and is constructed toprovide the requisite structural integrity as to be able to withstandmoments of inertia and other load factors. It is comprised of hardenedand corrosion proof materials and has bearing surfaces of a propermaterial to assure a smooth and stable motion as well as reducedfriction and wear.

The Drive Mechanism incorporates a self-locking mechanical drive (i.e.worm drive, or screw jack), and is thereby able to avoid the possibilityof reverse torque from altering position. It eliminates the need toprovide constant power to the actuator (motor) as a means of holdingposition, and avoids the potential of premature wear or failure.

The Hydraulic Actuator provides the force to power the Drive Mechanismas to control and manipulate the Mechanical Coupler. It is fabricatedfrom corrosion resistant materials, is sealed in an environmentalhousing, and is further protected by a bath of dielectric oil.

The Bus Sub Assembly consists of the Bus Conductors (power andcommunication) within the Joint Assembly and the requisite Bus Couplerto transfer Bus Conductor connections across the motion of themechanical coupler (i.e. inline, linear, radial, or rotary). It ispackaged in an environmentally protected housing to protect againstcorrosive elements and may be co-located with the Control Sub-Assemblywithin the same housing.

The Control Sub Assembly includes a positioning sensor to indicate theposition of travel of the mechanical coupler, additional associatedsensor arrays as required to instrument articulation issues (e.g.,speed, acceleration, force, pressure, and resultant environmental orother conditions), means to collect and transform sensor data intomeaningful feedback in support of autonomous operation, andinterpolation of sensor feedback into a self-model of localizedconstraints and ‘reflexes’ (stimulus-response without override).

Each module and assembly contains within itself the above describedon-board intelligence and instrumentation, and physical and mechanicalmeans, These are synchronized in an on-board and internal self-model,which is stored in the memory. The processing logic unit uses signalsfrom the instrumentation (e.g., sensors), both for performing designfunctions, and for enabling real-world comparison between the module'sself-model and the reality it currently senses and affects. The use of astandardized and encapsulated modular programming structure allowslocalized signal/sensory performance guidance as well as transmittablefeedback on goal attainment. Specific exception recording can accountfor unit deviation from standard expectations (e.g. wear-causeddegradation) without requiring or affecting overall reprogramming ofeither the SROV or other modules.

As exemplified in FIG. 5A, the MCU (527) residing in Track Tool (350),decodes a command from Bus (1110) to make contact with the work surfaceas had been issued by the OC. In response, the Track Tool MCU (527)generates a signal onto the Bus requesting forward extension. Thissignal is decoded by MCU (517) located within the Extensible Arm Unit(1500). In response, MCU (517) activates Linear Actuator (513) to begina powered forward extension (515). Upon the inboard track making contactwith the work surface (531), the associated inboard track sensor (529)indicates contact via increased pressure. In response, Track Tool MCU(527) generates a signal onto the Bus to halt extension. The ExtensibleArm MCU (517) decodes this signal and in response, deactivates LinearActuator (513).

As exemplified in FIG. 5B, a similar process is repeated where the TrackTool MCU (527) generates a signal onto the Bus to square up the TrackTool upon the work surface. The MCU (557), located in Wrist Unit (1520),decodes the signal and in response activates Multi-Axis Actuator (553)to begin an axial articulation (555) to rotate the Track Tool down ontothe work surface. When the outboard track makes contact with the worksurface (561), and the associated outboard track sensor (559) indicatesequal pressure to inboard track sensor (529), in response, Track ToolMCU (527) generates a signal on the Bus to halt articulation. Wrist UnitMCU (557) decodes the signal, and in response, deactivates Multi-AxisActuator (553).

Sensors include any of the set of possible internal-to-the-modulesensors (e.g., position, orientation, speed, electronic resistance,magnetic, accelerometric, force, pressure or chemical differentiation,angular deflection, haptic, self-check diagnostics, and otherconditions) that are desirable to affect a feedback linkage betweencurrent condition and modeled norms for the module, both as to itsfunction and status.

Any of a number of specialized tools (e.g. grinders, propellers, treads,pumps, jets, welding apparatus, sealing apparatus, levers, hammers,jacks, grippers, caulkers, and other standard mechanical and physicalrepair and maintenance devices) can be an operable part of any modularcomponent, a device subject to that modular component's effort. Eachoperating tool, or device, or each actuator for placing the modularcomponent or SROV into the proper position, will be linked withappropriate external and internal sensors to form the feedback linkwhich can communicate the tool's effect on both the external environmentand the module and thus, on the SROV.

The SROV comprises a plurality of modules (inter-connectable via thepreviously described Module Interconnection Technology) categorized byfunctional types and having a common architecture. These include atleast the following types (FIG. 3): Frame Module, Shoulder Module,Articulation Module, and Hand Module.

A Frame Module (as shown in FIG. 13 and for the purposes of thePreferred Embodiment) is an articulatable “spine” (1300) that providesthe foundation upon which the SROV is built and forms its “core.” Toenable flexible navigation, either end of the frame is fitted with aMulti-Axis Joint Assembly (1350 and 1351). The Bus (1110) is passedthrough the joint assemblies terminating in a Plug (1130) and Adapter(1132) at the proximal end Socket (1131) and Adapter (1133) at thedistal end. Shoulder Modules may be connected to either end of the FrameModule, or alternatively, multiple Frame Modules may be interconnectedto extend the body of the SROV and expand its functionality, whilepermitting articulation. Enclosed in an environmentally protecting tube(1330) of the Frame Module are the following units, which contain all ofthe sub systems required to manage, monitor, operate and navigate theSROV, and including but not limited to:

The Master Module Control Unit (1310) to both receive control signalsfrom and communicate data signals to the CCU; to register (e.g.,identification, functionality, and configuration) and to then monitorand provide coordinated control of the modules and assemblies attachedto the Frame Module by the issuing of control signals to, and by theaggregating of data signals from, the MCUs located within these otherSROV modules and assemblies.

Module Control Unit (1312) specific to the Frame Module as to operateinternal Module equipment including the monitoring of thresholds ofsensors for values that have been or are about to be exceeded, and ifso, to generate signals onto the Bus indicating the need for correctiveaction, enabling either the CCU, the MMCU, or both operate and navigatethe SROV.

Sensor Bay (1314) to house sensors oriented to general operations andnavigation and that may include sensors to detect orientation (e.g.,lateral and longitudinal trim, depth, etc.), tilt (e.g., pitch, yaw, orroll), position (e.g., external references, transit, natural landmarks,or artificial landmarks from which SROV position may be computedrelative to a map), and control sensors to indicate all criticaloperational aspects of the SROV (e.g., fluid pressure, voltage, amperagetemperature, etc.).

The Hydraulic Power Unit (1316) converts electrical power into hydraulicfluid pressure so that it may be delivered through the power portion ofthe Bus. An electric motor, housed in a chamber of dielectric oil,extends its shaft through a rotary seal as to connect to a hydraulicpressure pump. The pump side of the chamber is filled with the hydraulicfluid that serves as the pump reservoir. The pump feeds into the supplyside of the Bus, while the return line of the Bus feeds back into thereservoir.

The Failsafe Unit (1318) provides emergency override and comprises a setof redundant critical components (e.g., MMCU and MCU, an AuxiliaryHydraulic Power Unit, an Emergency Control Unit, and an emergency powerback-up battery bank including a charging circuit). It implementssoftware and hardware to automate failover to those components in eventof a failure of primary components of the SROV. A back-up battery bankpowers SROV emergency procedures (e.g., shutdown, report, retraction,return or other).

The Failsafe Unit monitors signals and operational conditions via theBus. It may be triggered in response to receipt of an explicit commandor may be programmed to be triggered on a detection of wide variety ofinput signals, and predetermined or abnormal conditions such as powerfailure, component failure, loss of communication with the CU, etc. Ondetecting such a condition, it activates a corresponding failoverprocedure that may include emergency shutdown or other responsiveprocedure subject to situational constraints.

Failover or emergency shutdown procedures may, for example, retract allarticulators and place vulnerable electronics or mechanics in a safemode in preparation for manual extraction. Alternatively, an emergencySROV self-extraction program may be triggered, depending on the lastknown status report(s) available to the Fail-safe Unit, causing the SROVto “back out” of the conduit by at least partially reversing itsrecorded path. Additionally, a Fail-Safe Unit will have on-board memory,processing, and program components comprising the control and operatingmanagement device to implement automated operation of pre-programmed,situation specific tasks as best match up with the last signal inputsstored and received before the loss of umbilical-provided power; and aset of stimulus-response programmed activities stored in the on-boardmemory, against which the on-board processing component compares thelast signal inputs stored and received to determine and activate thebest matching response, using the same last signal inputs stored andbackup battery bank power limit as the situational constraints on theselection.

A Shoulder Module (FIG. 14) comprises a controllably rotating framearound a central shaft connectable to a plurality of ArticulationModules, and provides means for the radial rotation of a plurality ofArticulation Modules around a Central Shaft. A plurality of ShoulderModules may be configured in an SROV. Position and orientation, bothlocalized and global, of the rotating frame may be sensed via the Busand on-board sensors for the Shoulder Module or a specific sub-portionpertinent to a specific sensor.

The Shoulder Module (1400) specific components and assembly comprises:

A Central Shaft (1430) contains Bus (1110) and where the proximal end ofthe Central Shaft is affixed with Plug (1130) and Adapter (1132). Theshaft distal end is affixed to Socket (1131) and Adapter (1133). Thisallows the transparent interconnection and passing of Bus Resourcesbetween the Shoulder and Frame Module or between a plurality of ShoulderModules.

Rotary Joint Assembly (1444) is fitted to rotate upon Central Shaft(1430). The proximal end of a plurality of Sockets (1450) (four in thefigure) are affixed to Rotary Joint Assembly (1444) and preferablyarranged in a radial and equi-angular manner The distal end of saidsockets are affixed to Articulation Module Frame (1460).

A Bus Splitter (not shown) is installed within the Central Shaft as toprovide the Bus (1110) into the inner section of a Bus Sub-Assembly(1440) that is affixed to the Central Shaft (1430) adjacent to RotaryJoint Assembly (1444). Affixed to the outer section of said BusSub-Assembly is a second Bus Splitter (not shown) and in thisembodiment, the outputs connect the Bus (1110) to the Sockets (1450)(four in the figure), and to the MCU (not shown) for the purpose ofgoverning Drive Sub Assembly (1442) co-located with Bus Sub-Assembly(1440).

A Protective Cover is installed on either side of the Articulation Frameand comprises a Top Section (1470) and Bottom Section (1472).

The Articulation Module consists of a plurality of inter-connectabletypes of Units, deployed in various configurations to provide greaterarticulation, and that singly or in combination will comprise a completeArticulation Module:

Specific types of Units include at least: (1) (FIG. 15A) An Elbow Unit(1530) to provide means for redial realignment of an Arm Unit and may beconfigured in a plurality of different angles; (2) (FIG. 15B) A WristUnit (1520) incorporating a Multi-Axis Joint to provide multi-wayarticulation and rotary positioning; (3) (FIG. 15C) A Fixed Arm Unit(1510) that may fashioned in a plurality of lengths; (4) (FIG. 15D) AnExtensible Arm Unit (1500) that incorporates a Sliding Joint Assembly asto be able to extend and retract; and, (5) a Brace Unit (1540)comprising a plurality of means to increase structural bracing andstability.

The proximal end of each Unit (excepting the Brace Unit) is affixed witha Plug (1130), while the distal end is affixed with a Socket (1131) toenable passing of Bus Resources between Units and/or Modules via theBus.

One embodiment of a combination of Shoulder and Articulation Modules isshown in FIG. 4A and where Shoulder Module (1400) can be configured toseveral modular Units, and where these Units have a standard means ofinter-connection as to provide a wide range of configurationversatility, and in this view includes the Extensible Arm Unit (1500)and the Wrist Unit (1520) and to which is affixed a Track Tool (350). Asshown in FIG. 4B, the Extensible Arm Unit (1500) includes a poweredextension and retraction capability. As shown in FIG. 4C, the Wrist Unit(1520) includes a powered multi-axial articulation capability.

The Hand Module (1610) functions as an integration platform between theSROV and Tools used by the SROV. The proximal end of the Hand Module isfitted with a Plug to pass Bus Resources into an MCU and an AuxiliarySocket located in the Hand Module Frame. The distal end of the HandModule is conformed into a mounting plate (1620), to stably and robustlyaffix it to an associated Tool. Incorporated into the mounting plate isa Socket featuring additional power conductors to distribute a pluralityof channels of power under the control of the MCU, for utilization bythe Tool. A Developer Kit, preferably operable upon a personal computer,facilitates integration of a specific Tool into the Hand Module.Developers can to easily and seamlessly integrate third party tools intoSROV operation by defining tool specifications, physical characteristicsand SROV reciprocal requirements or constraints so they may be stored inthe Hand Module MCU in a standard format. Tool functionality can bemapped in terms of signals, commands, or other command, control, andsensor language elements so that, from the perspective of the MMCU andthe CCU, or other modules, signals to and from a Hand Module use thesame interface as any other module. Mechanically, Tool developers needbe concerned only with providing mechanical connection to the HandModule Socket, creating distribution of power into the appropriatenumber of controllable channels, and connecting signal conductors fromthe Tool to the communication portion of the Bus. If analog controls orsignals are necessary in the Tool, analog-to-digital ordigital-to-analog conversion is the responsibility of the Tool provider.This easy, standardized and prepackaged access to power andcommunication, in combination with a CCU Developer ProgrammingInterface, enables field engineers to quickly adapt existing or newgeneration tools into the SROV system.

The following types of Tools are disclosed for purposes of the PreferredEmbodiment.

A Tractor Tool (350), to provide a means for “crawler” type controllablepropulsion. A Male Tool Mounting Plate is attached to the top of theTractor Frame. Internal to the frame is a Rotary Joint Assembly thatdrives a geared Tractor Drive Wheel Assembly. A set of Dual Tracks, arefitted to the drive wheels to assure a high degree of traction, and theability to navigating misaligned surfaces. In the preferred embodiment,a Tractor Tool comprises of a set of hydraulically powered,trackencircled wheels for engaging a multiplicity of surface types andangles, and thereby providing a high degree of traction, and ability tonavigate misaligned surfaces.

The Thruster Tool, (not shown) provides means for “swimming” typepropulsion. It consists of a mounting plate, and frame containing aRotary Joint Assembly that is used to power an impellor and that isenclosed within a cylindrical cage.

The Debris Removal Tool (FIG. 16) provides a means to controllablyremove high volumes of material from a surface. A Hand Module, (1610) isattached via its Mounting Plate (1620). A Rough Cut Unit (1630) (i.e.,any tool capable of cutting, ripping, chipping, tearing, or digging awaydebris down to a uniform stubble), in this embodiment, consists of apair of closely spaced, counter-rotating, carbide toothed, circularblades, and where the counter-rotation of dual blades offsets thetransfer of potentially damaging moments of inertia, should the bladesencounter difficult debris conditions. A Fine Cut Unit (1640) (i.e., anytool able to remove the stubble and/or polish the surface), in thisembodiment, consists of a plurality of shafts featuring a spring loadedshaft insert (providing conformance to minor work surface variations).The distal end of said shaft insert is threaded in order to acceptindustry standard cutting brushing, and polishing implements so as toenable selection from numerous alternatives and deliver best practicerestoration of work surface conditions. For illustrative example, spurpolishers are shown in the figure.

The SROV Debris Recovery Tool (FIG. 17) provides means to controllablyrecover debris in an environmentally responsible and regulatorycompliant manner. A pair of Hand Modules (1610) is attached to each sideof the Debris Recovery Frame. The Hopper Mouth (1720) is preferablyadjustable (e.g., via adjustable side skirts that conform to the surfaceor via a hydraulically inflatable and conformable wire mesh) and thatconform to surface of conduit. Water Jets (1735), located in the HopperMouth, are powered by a pump (1730), and direct debris back into theCrushing Mill (1740). An acquisition upper and lower roller pairfeatures interlocking tine shaped teeth that engages the debris andreduces it to a uniform smaller sized chunks. A second roller pairreduces debris into a small particulate, while a final set reducesdebris into a slurry. The rear of the hopper contains an Ejection Pump(1750) (e.g., a trash pump or other pumping means), which moves debristhrough the debris line. A set of variable size collets supportdiffering diameter of debris line hose (1760).

The SROV Inspection Tool (FIG. 6) comprises a variety of sensor hardware(611) and enables flexibility in mounting location (e.g., an extensibleprobe (610) projected in front of or behind the SROV), and interfaces tothe Bus via the MCU in the Hand Module. One configuration may use amounting plate onto a Hand Module for resource and attachment. Anotherconfiguration may use an Auxiliary Socket as resource and mechanicalattachment. An alternative may include the use of an Umbilical Bus toallow remote positioning of the enclosure and attachment by means of aclamp. Multiple inspection and sensing modalities are enabled so as toreduce reliance upon visual devices (e.g., remote camera monitored by aremote operator) or human vision. Inspection activities may includereal-time before and after sensing of work process performance,resultant surface finish and sub-surface structural condition, or theenvironment mapping to support navigation, orientation, and positioning.Signals from these sensors are transferred to the surface via theUmbilical, where they may be further analyzed and recorded by the CCU.Inspection sensors may be incorporated into SROV tools such as theDebris Removal Tool (1600), Track Tool (350), or Debris Recovery Tool(1700). Signals are selectively transferred to the surface via thecommunication portion of the Bus and the Umbilical, where they may befurther analyzed and recorded by the CCU. Types of sensors well-known inthe art and easily adapted for use in the Inspection Tool or elsewherein the SROV include, for example, video, infrared, ultra sonic, sonarimaging, and eddy-current. Other types of sensors will be readilyapparent to those of ordinary skill in the art.

Sensors can also be used for external examination of the SROV, MP, andconnections for ‘self-check’, removing a major problem with many ROV andautomated operations when the problem arises from the device, not theenvironment or operations. Types of sensors well-known in the art andeasily adapted for use in the Inspection Tool or elsewhere in the SROVinclude, for example, video, infrared, ultra sonic, sonar imaging,thermal, conductivity, and eddy-current. Other types of sensors will bereadily apparent to those of ordinary skill in the art including, butnot limited to, wired, wireless, tactile, inertial, corrosion, pH,position, ultrasonic flow, incline, pressure, voltage, current, flow,payout, tilt, gas composition, imaging, bump, debris, edge, gascomposition, environmental, robot tilt, temperature, humidity, hydraulicpressure, pneumatic air pressure, gamma ray, neutron, electrical,acoustic, location, accelerometric, haptic, particulate assessment,multiple-sensor arrays, and so-called Lab-on-a-Chip (including those forgenetic or DNA analysis). Sensors may be integrated usinganalog-to-digital or digital-to-analog converters as necessary.

Functional programming for tool-specific operation is encapsulated witheach hand module; sensory records and reports can be thus used toiteratively adapt and improve the SROV with a succession ofbetter-designed Hand modules specific to the localized needs, withoutrequiring the entire SROV to be recalled and redesigned.

Other types of Tools will be readily apparent to those skilled in theart such as, but not limited to, tools for grasping; clamping; objectmanipulating; object handling; pipe cleaning; barrel cutting; lateralcutting; rotating rasp; root cutting; pipe cleaning; lateral trimming;high pressure jet; pipe joint sealing; pipe joint testing; pipeprofiling; pipe sampling; drilling, pipe installation, pipe sealing, andinternal repair.

Standardized connections between modules and the ability of controlunits within modules to be interconnected (both mechanically and withrespect to Bus Resources) and to communicate and identify themselves toother control units. Aggregate configuration, monitoring, control, andfunctionality of an SROV resulting from interconnection are made knownto both the MMCU and the CCU without mechanical or softwarereengineering. The modules described herein may be interconnected with“plug-and-play” simplicity to provide the SROV with the functionalitynecessary for a wide range of work processes and environments. Fieldoperations personnel can easily configure SROV modules (see, forexample, FIG. 3) and in support of an unlimited array of work processes,environments, and achieving the automated remediation for any of thefollowing:

The configuration (FIG. 10A) to function in a small conduit, where ashortened Extensible Arm Unit (1505) is utilized.

The configuration (FIG. 10B) to function in a very large conduit, wherea Full Size Extensible Arm Unit (1500) is used in conjunction with FixedArm Unit (1510), and supported by a Brace Unit (1540).

The configuration (FIG. 10C) to function in a rectangular conduit andwhere additional Shoulder Modules are utilized and where each only has apair of opposing Extensible Arm Units (1500) and where the ShoulderModules operate in a reciprocal fashion as the Arm Units extend andretract, and the Wrist Units articulate in order to conform to the worksurface.

The configuration (FIG. 10D) to function on an exterior surface (e.g.conduit exterior) and where the Frame Module is not a “spine” but a wraparound “exo-skeleton” (1040) and where the Track Tool may incorporateadditional special purpose attachment equipment (e.g., electromagneticattachment, grappling arms, vortex generators, or clamps).

The configuration (FIG. 10E) to function on a flat surface.

The SROV control system hardware and operating environment functionalityis described herein in terms of a computer executing computer-executableinstructions. FIG. 20 illustrates one control system hardware andoperating environment (2000) in conjunction with which some embodimentsof the SROV and its supporting equipment is implemented. Someembodiments of the control system can be implemented entirely incomputer hardware with the computer-executable instructions implementedin read-only memory, some entirely in software, and some in acombination of hardware and software. Some embodiments can also beimplemented in client/server computing environments where remote devicesthat perform tasks are linked through a communications network. Programmodules can be located in both local and remote memory storage devicesin a distributed computing environment. Some embodiments can also be atleast partially implemented in a quantum mechanical computing andcommunications environment or using analog devices. Computer (2002) mayinclude a processor (2004), commercially available from Intel, Motorola,Cyrix and others. The Computer can also include randomaccess memory(RAM) (2006), read-only memory (ROM) (2008), and one or more massstorage devices (2010), and a system bus (2012) that operatively couplesvarious system components to the processing unit. The memory and massstorage devices are types of computer-accessible media. Mass storagedevices are more specifically types of nonvolatile computer-accessiblemedia and can include one or more hard disk drives, floppy disk drives,optical disk drives, and tape cartridge drives. The processor can becommunicatively connected to the Internet (2014) (or any communicationsnetwork) via a communication device (2016). Internet connectivity iswell known within the art. In one embodiment, a communication device isa modem that responds to communication drivers to connect to theInternet via what is known in the art as a “dial-up connection.” Inanother embodiment, a communication device is an Ethernet™ or similarhardware network card connected to a local-area network (LAN) orwireless LAN that itself is connected to the Internet via what is knownin the art as a “direct connection” (e.g., Ti line, etc.). A wirelessrouter (2040) may be interfaced to the system bus as another means toconnect to the Internet.

A user enters commands and information into the computer through inputdevices such as a keyboard (2018) or a pointing device (2020). Thekeyboard permits entry of textual information into computer, as knownwithin the art, and embodiments are not limited to any particular typeof keyboard. The pointing device permits the control of the screenpointer provided by a graphical user interface (GUI) of operatingsystems such as versions of Microsoft Windows™. Embodiments are notlimited to any particular pointing device. Such pointing devices mayinclude mice, touch pads, trackballs, remote controls and point sticks.Other input devices (not shown) can include a microphone, joystick, gamepad, gesture-recognition or expression recognition devices, or the like.

In some embodiments, computer is operatively coupled to a display device(2022). The display device can be connected to the system bus andpermits the display of information, including computer, video and otherinformation, for viewing by a user of the computer and embodiments arenot limited to any particular display device. Such display devicesinclude cathode ray tube (CRT) displays (monitors), as well as flatpanel displays such as liquid crystal displays (LCD's) or image and/ortext projection systems or even holographic image generation devices. Inaddition to a monitor, computers typically include other peripheralinput/output devices such as printers (not shown). Speakers (2024) and(2026) (or other audio device) provide audio output of signals and mayalso be connected to the system bus. Numerous other input and outputdevices may be connected in various ways well known to those of skill inthe computing arts.

The computer may also include an operating system (not shown) that isstored on the computer-accessible media RAM, ROM and mass storagedevice, and is executed by the processor. Examples of operating systemsinclude Microsoft Windows™, Apple MacOS™, LinUX™, UNIX™. Examples arenot limited to any particular operating system, however, and theconstruction and use of such operating systems are well known within theart. Embodiments of computer are not limited to any type of computer. Invarying embodiments, computer comprises a PC-compatible computer, aMacOS™ compatible computer, a Linux™-compatible computer, or a UNIX™compatible computer. The construction and operation of such computersare well known within the art.

The computer can be operated using at least one operating system toprovide a graphical user interface (GUI) including a user-controllablepointer. The computer can have at least one web browser applicationprogram executing within at least one operating system, to permit usersof the computer to access an intranet, extranet or Internet world-wideweb pages as addressed by Universal Resource Locator (URL) addresses.Examples of browser application programs include Modzilla FireFox™ andMicrosoft Internet Explorer™.

The computer can operate in a networked environment using logicalconnections to one or more remote computers, such as remote computer(2028). A communication device coupled to, or a part of, the computercan achieve logical connections. Embodiments are not limited to aparticular type of communications device. The remote computer can beanother computer, a server, a router, a network PC, a client, a peerdevice or other common network node. The logical connections depicted inFIG. 20 include a local-area network (LAN) (2030), wireless LAN (2024)and a wide-area network (WAN) (2032). Such networking environments arecommonplace in offices, enterprise-wide computer networks, intranets,extranets and the Internet. When used in a LAN-networking environment,the computer and remote computer are connected to the local networkthrough network interfaces or adapters (2034), which is one type ofcommunications device. The remote computer also includes a networkdevice (2036). When used in a conventional WAN-networking environment,the computer and remote computer communicate with a WAN through modems(not shown). The modem, which can be internal or external, is connectedto the system bus. In a networked environment, program modules depictedrelative to the computer, or portions thereof, can be stored in theremote computer. The computer also includes power supply (2038). Eachpower supply can be a battery.

Distributed control maximizes SROV autonomous operation underintelligent planning and control, while retaining the possibility ofremote monitoring, override and control. Each tier of control (in thisembodiment) is comprised of a computer, having at least a processingunit, 110 unit, memory, and one or more software programs.

The Distributed Control System (FIG. 18) is distributed across aplurality of tiers—three in the preferred embodiment (1800): (1) A CCU(1801) comprising a computer and an operator interface for remotecontrol as well as programmed control and monitoring necessary tosupport autonomous robotic operation, and connection to the Frame Modulevia Umbilical; (2) A MMCU (1803) for the overall control of the SROV;and, (3) A MCU (1805) for the internal control of each module within theSROV, including autonomic operation;

The first tier implements computerized control and monitoring of theentire system (including possibly multiple SROV deployments) fromplanning through operation and SROV retrieval. The CCU is used todevelop and download SROV work plans (i.e., high level programs orscripts) to implement, for example, the remediation of a specificsubmerged infrastructure. During SROV operation, the CCU comprises atleast one operator interface to externally control the SROV via signals(both manual and programmatic fly-by-wire) and for receiving andprocessing monitoring signals from the SROV. The CCU may include aremote computer that can be accessed via switch (1802). The first tiercommunicates and is interconnected with the second tier.

The second tier implements control at the SROV level. As someimplementations call for additional an SROV (1807), a separate MP (1804)is associated with each SROV being deployed. A network (1810) connectsthe CCU to the MP. The MP contains an Umbilical (1811) that connects thenetwork to the SROV and, in particular, the MMCU. Within each SROV(typically in the Frame Module) resides a MMCU which detects, recordsand registers the SROV configuration (i.e., which modules have connectedto the Bus, where, and their functionality); monitors and coordinatesthe movements of the various modules of the SROV; controls powerconditioning and distribution; manages signal distribution; and monitorsSROV parameters (e.g., position, travel, routing through the conduit,etc.); and navigates the SROV. The MMCU is responsible, for example, forpreventing module movements from colliding with each other (e.g., byconstraining their movements to mutually exclusive regions), forcontrolling their rates of performance relative to each other, andsimilar coordinating functions. The second tier also communicates and isinterconnected with the third tier.

The third tier implements control at the module level of the SROV.Within each SROV module resides the SROV Bus (1812) that passesResources to each module of the SROV. Within each module resides an MCU(1805) providing embedded intelligence. Each MCU is connected to aSensor Interface (1831 and 1832) to monitor sensors (1836 and 1837). Inthe case of an additional SROV, an additional Sensor Interface (1833 and1834) monitors sensors (1838 and 1839). Each MCU aggregates, formats,and uploads sensor data to other Control Units; accepts externallyprovided instructions; and controls the detailed operation of thespecific module responsive to externally provided or preprogrammedinstructions. It also manages its connection (via the Bus) to thenetwork.

Each MCU is also connected to an Articulator Interface (1821 and 1822)to operate actuators (1826 and 1827). In the case of an additional SROV,an additional Articulator Interface (1823 and 1824) operates additionalactuators (1828 and 1829). Responsive to instructions, a MCU may causethe articulated movement of a module to perform a complex movement once,to repeat a pattern of movements, or to perform obstacle detection,obstacle avoidance, or obstacle following independent of what othermodules are doing.

Information about a submerged infrastructure may be loaded into the CCUand used to develop the set of instructions that will implement adesired Work Plan or process. For example, the physical layout andgeometry of the submerged infrastructure may be captured usingblueprints or their electronic equivalent, and inspection data used toidentify obstacles, irregularities, fouling, and obstructions. From thisinformation, simulation facilities are used to develop the SROVconfiguration requirements and a work plan. A work plan will typicallyinclude a path for navigation of the infrastructure, and commands forconfigured modules as the SROV transits the path. The work plan is thenconverted into a program to be downloaded from the CCU to the MMCU thatis located in the SROV.

The CCU is used to develop and maintain a library of Solution Patterns.Each Solution Pattern is a set of instructions (as embodied in, forexample and without limitation, an interpretable script, compilablesource code, subprogram, precompiled program module, DLL, firmware,etc.) for the SROV or any control unit corresponding to a specific workrequirement and/or SROV configuration. Typically, a Solution Patternwill specify a particular behavior of the configuration (such as apattern of one or more senses and responses implemented via sensors andactuators). A Solution Pattern may be used to effect the coordination orsynchronization of multiple modules. For example, one Solution Pattern,having a specific SROV configuration as a requirement, causes a DebrisRemoval Tool to remove crustaceans from a conduit having a roundgeometry, with the diameter of the conduit as a function of SROV radialextension and length of SROV travel being a deployment parameter. TheSolution Pattern may incorporate obstacle (or other deviation) detectionand automatic obstacle following so that the Debris Removal Toolindependently removes crustaceans around the obstruction withoutcolliding with it. Other Solution Patterns address, for example,autonomous navigation, autonomous inspection, autonomous remediation,monitoring requirements, detecting and working around types of obstaclesor irregularities, autonomous pre-remediation and postremediationinspection, and so on. Solution Patterns may be combined, possibly withcustom programming or live operator instructions, to form a completework plan as needed to accomplish a particular remediation.

Solution Patterns can be linked to the specific tool or combination oftools, sensors, and SROV design for the goal(s) that the SROV'soperator, user, or customer wishes to effect. Because of the modularsoftware and physical architecture, designers can focus on the specificsof each Tool unit they wish to provide; or SROV users can put out forbid and design their needs for upcoming or experienced taskings.

During operation, the CCU coordinates the SROV and non-SROV subsystems(including the MP). The operator interface of the CCU preferablyincorporates a virtual, three-dimensional portrayal of the work area,the SROV as configured, and activities of the SROV, combining pre-loadedsubmerged infrastructure data with sensor data from the SROV duringoperation. For example, a previously acquired and loaded visual image ofthe work area may be overlaid with schematics, plots, and identificationof obstacles, deviations, or other data. This data may be acquired, forexample, by separate inspection or by the SROV during operation.Optionally, a representation or image (e.g., previously recorded,acquired from a camera, simulated, etc.) of the SROV may be incorporatedto show its position, orientation, and movements with respect to thework area. Preferably, the operator may change perspectives and viewingangles, zoom in and out, directly test the operating conditions using a‘haptic’ interface to verify the feasibility and/or safety of a Tool'soperation, and control other viewing or display options so as tooptimize monitoring, interaction, and control. This method eliminatesthe “operator blindness” endemic in prior art. When an operator mustrely on remote cameras, productivity diminishes as turbidity and debriscloud the work environment. The SROV simultaneously provides theoperator with an accurate remote visual experience of the operation,enhanced by various simulated views of SROV position and orientation,and direct measures of work progress. Monitoring of SROV internal statusvia sensors (limited self-awareness') permits comparison to the plannedgoals of the current tasking, enabling adaptive response to changedconditions whether of infrastructure or SROV.

During operation, the CCU records Operator Instructions (Sensor Data(both from the SROV and from the MP), and correlates it with theSolution Patterns being used. Performance, unanticipated events, anderrors are analyzed in real-time and corrective actions taken, eitherautonomously or under operator control. In addition, using accumulateddata about the effectiveness of a particular Solution Pattern andcomparison of Solution Patterns, Solution Patterns are optimized forperformance (e.g., by selecting those movements that remove a particulartype of debris the fastest), made more robust and flexible (e.g., byproviding multiple, alternative Solution Patterns), made more autonomous(e.g., by preprogramming a broader range of actions responsive todetectable sensor data patterns), and become responsive to unforeseenconditions (e.g., having a Solution Pattern for working around aprotruding but previously undetected pipe). The linkage of internalmodular sensory and status information prevents the futility ofattempting work beyond the capacity of the Tool and SROV on site whichhas been damaged or when in an environment beyond its safe limits.Methods well known to those versed in the art of expert systems (forexample, rule based or neural net systems) are applied so that the CCU(and therefore the SROV) can learn about its environment and adaptduring operation. This technology is particularly well suited toimproving SROV navigation using methods well known in the art forobstacle detection, obstacle avoidance, and path planning.

The MMCU receives SROV configuration requirements from the CCU. It thensenses and compares the current configuration of modules to the requiredconfiguration, providing feedback to the CCU in case of discrepancies.Preferably, the MCU continuously integrates and compares the internalmodel of the SROV system and its environment against the experienced andperceived current state of both the operating environment and itsphysical status and capacity. This is particularly useful in the eventof a module failure (e.g., loss of module connection or function), andenables adjustments and compensation for the loss, or extraction andrepair.

The MMCU also downloads Control Templates from the CCU and distributesthem to the intended MCUs (optionally as firmware upgrades). ControlTemplates provide instructions for translating high-level operationalcommand strings into a correlated set of low-level command streamstargeted to a specific module, and for translating between internalsignals from a sensor to a data format for inter-module communicationand for communication to the remote control means (e.g., CCU). Forexample, it may be implemented as a software translation table havingmeans for parameter substitution, and downloadable to a Control Unit asfirmware. This enables the CCU to reprogram modules or to expand andalter the set of high-level commands to which the SROV and its modulescan respond. The same Control Template is used by the MMCU to associateand aggregate sensor data with high-level commands, and upload a morecoherent status to the CCU. Control Templates are also used by the MMCUto translate commands and sensor data between modules for purposes ofsynchronization and coordination during operation. This provides theflexibility for the MP or OC level of control—the ‘human operator’—todetermine whether it will be better to run multiple passes, or to beginat one while simultaneously sending down multiple task-special units toallow, post-modification, multiple-Tool applications on a singlepass—with appropriate ‘corrections’ for the just-affected target.

The MCU accepts low-level commands from the MMCU via the SROV Bus anddecodes those commands into Peripheral Control Signals that governactuators (e.g., electrical solenoids, fluid control valves for theoperation of Joint Assemblies, etc.). The MCU (1805) aggregates currentreal-world status data (returned by sensors (e.g., joint assembly,motion, positioning, and inspection sensors), compares this againstcurrent functions and goals within its operative hierarchy, and uploadsthis Combined Status back to the MMCU.

The SROV Distributed Control Architecture (FIG. 18) implementscomputerized and integrated command and control of the SROV. Thisarchitecture comprises Physical Interfaces for operator input andoutput, sensors, and actuators. Each physical sensor and actuator isconnected to the communication portion of the Bus (preferably via aMCU), which provides network interconnection for the system. Analogsensors and actuators preferably incorporate analog-to-digitalconverters for output (data) and digital-to-analog converters for input(control) so that all data is in a Common Digital Bus Format accessibleto the software system. In addition to providing measurement andmonitoring signals as output, some sensors may be controllable andaccept input signals to control any of, for example, on and off status,positioning, resolution, data rate, and so on.

Similarly, in addition to accepting input signals for control purposes,some actuators may provide status, measurement and monitoring signals.All of these Signals are shared between system components via thecommunication portion of the SROV Bus.

Higher tiers may override any preprogrammed or otherwise automatedresponse of a lower tier. Lower tiers signal higher tiers when that tieris sensing a problem such as out-of-limit resistance to movement,functional failure, and so on. In appropriate circumstances, a first MCUmay send messages directly to a second MCU as, for example, to morerapidly avoid local collisions. This cross-tier, closed loop control andsensing system maximizes opportunities for response, adaptability, andautonomy.

The SROV Control Architecture's tiered hierarchy enables ‘real-time’operation for the SROV and any subordinate grouping of its modules. Itshould be noted here that the use of the term “real-time” within thisapplication does not denote either instantaneous time or the minimaltime for computer processing of a control determination. The concept ofwhat constitutes “real-time” SROV operation depends upon number ofdifferent factors, including the given application, the time constraintsfor that application, and the internal and external conditions. Forexample, an asynchronous communication link could be considered‘real-time’ if the packets are exchanged on a very high-speed network,if the response must engage the reading, comprehension, and reaction ofa human at one end, even though the individual packets may betransmitted (and even lost and retransmitted) in microseconds.

Accordingly “real-time” must incorporate the boundaries of operative andcommunicative delays imposed by competing signal needs for the Bus;normal, current, and extraordinary signal density relating to operationof the SROV and module(s); the distance between sender and receiver(doubled for higher-level feedback or override control commands), andlike real-world factors. Remote operation, whether by human‘telepresence’, wireless radio signaling from a remote mainframe, or anymixture of human and off-location computer guidance, will also belimited to the transmission speed and information capacity of the Bus.If the motion of the SROV is measured in centimeters per second, ahalf-second delay in transmission around the half the globe to acentralized human command center may well be a meaningful delay whenedging up to a hazard; alternatively, the entire operation of placing aseal on a pipeline leak may be considered a ‘real-time’ effort.

In this application, ‘real-time’ refers to the totality of asensor-response feedback loop in the physical world as opposed to aninternalized model or partially-enacted hardware effort, or an attemptthat has no real-world effect on the intended goal unless and untiltransformed into the final and completed operation. The degree to whichan application is “real time” is largely a measure of the speed withwhich the application can detect (i.e., perceive, sense or compute) asituation and react appropriately (e.g., providing the information to auser, automatically correcting a detected problem, or otherwiseresponding).

The functional software architecture (1900) of the SROV comprises atleast the following programmable subsystems, each encapsulatable in thepreferred embodiment so as to minimize control-and-status and/orfeedback signaling load on the Bus:

Command and Control Subsystem—The Command and Control Subsystem (1920)is the main subsystem that coordinates process and data flow among theother subsystems, however distributed. Responsive to signals from theInterface Subsystem (1926 and 1928), it invokes the functions (1922)required for any design, simulation, and operation task. Other functionsinclude storage and retrieval (e.g., infrastructure specifications, workprocesses, Solution Patterns, configurations, sensor data, histories,etc.), system functions (e.g., startup, shutdown, backup, recovery),system health check and monitoring, automated system failover andrecovery, download (e.g., configurations, Solution Patterns, ControlTemplates), upload (e.g., status, configuration, sensor data), andemergency SROV recovery procedures. Configurations include computerreadable descriptions of modules, sensors, actuators, and softwarereflective of a particular SROV configuration. Optionally, the Commandand Control Subsystem maintains a complete record or “history” of everydesign, simulation, and operation task that is performed on the system.These histories are used for, for example, additional simulations, newwork process or Solution Pattern design, optimizations, and auditingpurposes and is stored in the Library (1924).

Interface Subsystem—The Interface Subsystem (1910) manages and drivesall operator interfaces, including at least one interface (1912) foroperators to interact with the software system, including output (e.g.,video display, audio, optics, speech generation, haptics, etc.) andinput (e.g., mouse and keyboard, touch, voice recognition,accelerometric, pressure, etc.). Types of interaction include design(including specification of infrastructure and its state, work process,Solution Patterns, and Templates), simulation, operation and may requireother (1916) types of interface. During operation, the InterfaceSubsystem combines data from, for example, the Sensor Subsystem, theIntelligent Planning Subsystem, and the Navigation Subsystem to providereal-time display of the SROV and its environment. Images (e.g., visual,sonar, ultrasonic, thermal, etc.) from sensors or previously recordedstill images may be overlaid with blueprints, schematics, computergenerated images or renderings (e.g., of fouling, debris, or obstacles),and supplemented with other sensor data. The Interface Subsystem alsocommunicates with the Command and Control Subsystem and SensorSubsystem, to allow the display of the difference between planned,current, and past conditions, thus allowing progress of any task to bemore accurately During simulation, these same facilities are usedwithout need to physically deploy the SROV to simulate a work process ortask, using sensor data that is either computer generated orpre-recorded. This simulation allows ‘failure simulations’ to testoperators' and system capacities to deal with the unanticipated, andusually unwanted, differences between model and goal.

Sensor Subsystem—The Sensor Subsystem (1930) manages all softwarespecific to physical sensors. It detects and registers (as part of theSROV configuration) sensors that are connected, receives and forwardscommands to sensors, receives data signals from sensors, performs sensorhealth checks, maintains a history of data, commands, and status instorage; aggregates and formats data and status, and sends data andstatus to other subsystems.

Actuator Subsystem—The Actuator Subsystem (1940) manages all softwarespecific to physical actuators, thereby controlling the relativepositions and movements of the

SROV modules relative to the Frame Module. It detects and registers (aspart of the SROV configuration) actuators that are connected, receivesand forwards commands to actuators, receives data signals fromactuators, performs actuator health checks, maintains a history of data,commands, and status in storage, aggregates and formats data and status,and sends data and status to other subsystems.

Planning Subsystem—The Planning Subsystem (1950) receives sensor dataand status, detects obstacles and other deviations from anticipatedsurface and infrastructure conditions (using, for example, maps,obstacle detection, and obstacle avoidance methods well-known to in thearts pertaining to robotics), develops plans (i.e., positioning andorientation commands necessary to negotiate the deviation and achievethe navigation goal using methods well-known to in the arts pertainingto robotics), and sends (1952) plans and information describing detecteddeviations to other subsystems. From a record of the insertion andtransit of the SROV and its current position, the Planning Subsystem maycompute an exit path and commands to implement the exit path.

Navigation Subsystem—The Navigation Subsystem (1960) receives signalsand data relevant to SROV position and orientation, interprets thosesignals, determines SROV position and orientation, and forwards thisinformation (1962) to other subsystems.

Positioning Subsystem—The Positioning Subsystem (1970) controls SROVposition and orientation. It accepts SROV position and orientationsignals, commands pertaining to SROV position and orientation, andgenerates and sends commands (1972) to the Actuator Subsystem to modifyposition and orientation by actuating the SROV Propulsion Subsystem.

Debris Control Subsystem—The Debris Control Subsystem (1980) manages allsoftware pertaining to physical debris, including removal, recovery, andreclamation. It receives signals pertaining to SROV position andorientation, debris removal rate (e.g., from sensors in a Debris RemovalTool), and debris recovery rate (e.g., from Debris Recovery Tool orsensors measuring turbidity), and coordinates (1982) the rates of SROVtransit, debris removal, debris recovery (e.g., to maintain uniformremediation, avoid infrastructure abrasion, removal system clogging,jamming, etc.), dredge pumping, and debris reclamation.

Each of these functional subsystems may be implemented on one or morecomputer systems, and distributed in any convenient manner.Functionality may be distributed (i.e., be partitioned or replicated) innumerous ways. For example, in the preferred embodiment, these functionsmay be distributed across different computing tiers (e.g., CCU, MMCU,and MCUs of the preferred embodiment), across multiple SROV modules(e.g., Frame Module, Shoulder Module, Articulation Module, and HandModule of the preferred embodiment), or some combination.

Many functions supporting the SROV are better managed from the surface.This support is provided by the MP, situated to best manage deploymentfunctions including those associated with the Umbilical and Debris Line.The OC manages power and communication functions.

The MP (211) manages the deployment and recovery of the SROV, the SROVUmbilical and Debris Line, and automates the synchronization of theUmbilical and Debris Line with the travel of the SROV under monitoringand control of the CCU. This includes collocating, managing, andsynchronizing the travel of the Umbilical (212) and Debris Line (213)that are housed on the platform and connected to the SROV.

The Umbilical supplies both power to the SROV and communication (i.e.both sensing and control signals) between the SROV and othersub-systems. The Umbilical is environmentally protected, constructed asto maintain neutral buoyancy, resist abrasion, and re-enforced to allowits use as a retraction tether. The proximal end of the Umbilical isfitted with an Umbilical plug while the distal end is fitted with anUmbilical Socket (383). The Power Management Unit (381) features anUmbilical Plug at its proximal end in order to attach to the UmbilicalSocket (383). It features a Socket and Adapter at its distal end so asto attach to the rear of the SROV. The Power Management Unit contains aStep-down Transformer, and Power Supply Components, to transform thehigh Umbilical transmission voltages into the proper voltages andamperage to power the SROV Bus.

The Debris Line is a flexible conduit for moving debris from the SROV upto the surface, in order to allow the transfer of debris into a DredgeSpoil Reclamation Facility. The Debris Line may be deployed inconjunction with the Umbilical or separately. In one variation of theillustrative embodiment the Debris Line is a standard dredge line. Inanother variation it is physically integrated with the Umbilical. TheUmbilical and the Debris Line are instrumented with sensors that providemeasures of payout, position, operating, and health status to at leastthe CCU. The MP, since it will be the principal human operationalcontrol center for a specific SROV, will have a monitoring andoperational control station to monitor and control the umbilical anddebris line connections and operations linking the SROV with the MP andOC. Thus the MP for each SROV will have means for extending andretrieving the umbilical; umbilical positioning means for extending andretrieving the umbilical; umbilical placement means for managing therotational and directional position of the umbilical, or a sub-portionthereof; a debris retrieval line; debris retrieval line positioningmeans for extending and retrieving the debris retrieval line; debrisretrieval placement means for managing the rotational and directionalposition of the debris retrieval line, or a sub-portion thereof; debrisretrieval line operating means for activating, operating, and shuttingdown the debris retrieval line; means for directing the output from thedebris retrieval line into a targeted deposit area or volume; and, meansfor monitoring the status of the umbilical, the debris retrieval line,the debris retrieval line positioning means, the debris retrieval lineplacement means, the debris retrieval line operating means, and thetargeted deposit area or volume.

This platform is preferably constructed from a modified shippingcontainer, allowing for easy transshipment and is a self-contained,enclosed structure. The top cover lifts away to expose the platform andthe cover then serves as the facilities shed during deployment. Standardcontainer doors provide access and the opposing end of the containerfeatures a spare parts locker that, among other things, provides for thestorage of a set of floor panels. A Distribution Panel, located adjacentthe locker, allows for connection of power and communication lines to OCPower and the further connection to the platform Junction Box.

The Umbilical Supply Reel Unit (214) located on the platform is used topay out and take in the SORV Umbilical. This unit consists of amotorized base with the appropriate rotary coupler that has one sideconnected to the junction box, and where the other features an UmbilicalSocket in order to connect with a slide on spool containing the SROVUmbilical. Multiple spools may thereby be attached together for longdistance deployments. The platform has davits to support a removablecradle that houses the SROV during transshipment.

The platform may be positioned in various ways such as at the shoresedge or on a floating barge. Guide Sheaves and a set of associatedbrackets or anchors align the travel of the Umbilical from the supplyreel to the designated work area of the SROV. These Sheaves areinstalled in such a manner so as to allow the Umbilical to be used as aretraction towing line, in case of malfunction of the SROV. A DebrisLine Station stores, inserts, or removes sections of the Debris Line, aBooster Pump that can be inserted into the debris line to increase flowvolume, and transfers recovered debris into a Dredge Spoil ReclamationFacility.

The Umbilical features a replaceable outer abrasion jacket, woven from awear-resistant material, to protect the Umbilical. Under the abrasionjacket is a layer of highstrength woven fiber to provide the structuralintegrity and strength to allow the Umbilical to be utilized as a towingline as to retrieve the SROV. A thermoplastic flexible core, of theproper density to provide neutral buoyancy, encapsulates all of theconductors within the Umbilical. Individual conductors include Power,Communication and Systems Ground. Typical power conductors include aNeutral Power Conductor, Ground Conductor, and a plurality of HollowPower Conductors (typically three). The hollow portion for the insertionof Communication Conductors serves to minimize the negative impact onsignal quality from the surges in the power conductors as power isadjusted or fluctuates. Communication Conductors are wrapped in aninterference shield to further isolate the radio interference projectedby the high voltage alternating current. The communication conductor maybe a fiber optic cable fitted with its own signal shield and insulation.Alternatively in other Power Conductors, an Electrical Signal Conductormay be inserted).

The OC (230) is preferably a self-contained, enclosed structure havingenvironmental conditioning to protect human operators and sensitiveequipment. This equipment provides the ability to connect with a sourceof power, monitors and condition that power according to loadrequirements, support communications, and to control and monitor theSROV and MP. The CCU comprises both an operator interface for remoteoperation and means of monitoring the SROV. It further comprises meansto pre-program Control Units for autonomous operation, includingfunctions to monitor, respond to, present, display, record, and analyzesignals from the SROV. The OC can be remotely located and in real-timere-located or re-directed to specialist technician, operative(s), orsecure recording archive. It is constructed from a modified shippingcontainer to simplify transshipment, and that has been partitioned intoa maintenance area, an equipment area, and an operations area.

The Maintenance Room is entered through the standard container doors.The interior is fitted with a service bench, storage bins, shelves, anddiamond plate floor. All materials and equipment are properly securedfor container transshipment.

The Equipment Room consists of a dual bulkhead forming a room thatseparates the maintenance area from the operations area. A man door islocated in each bulkhead forming not only access to this room, but ahallway between maintenance and operations. Located within the equipmentroom is a forced air conditioning system to protect human operators andsensitive equipment. A fold up service mast accepts standard industrialpower (e.g., three-phase, 440 Volt), either from the grid oralternatively from an equivalent generator. The Power Control Center islocated between the bulkheads, and against an outside wall. The PowerControl Center transforms grid voltages, conditions and regulatesresultant electric power, as well as to provide overload and groundfault protection. A fail-safe electric power lockout assures that diversare protected if they must enter the water near the SROV or itsumbilical. The Power Control Center also has an interface to the controlequipment located in the Operations Room as more fully described below.

The Operations Room partitions the opposite side from the bulkhead inorder to enclose a lavatory, kitchenette, and bunk facilities. Theoperational side of this partition includes built-in closet and filingfacilities. A door and windows provide access, natural light and a viewof outside activities. The center of the operations area includes aconference table and chairs An Operator's Monitoring and OperationsStation and including a desk and equipment rack are built into theequipment room bulkhead. The enclosed equipment includes aCommunications Unit and supporting cellular, radio, landline, oralternatively satellite communications, with associated handsets, andfacsimile. A Power Monitoring Unit displays key electrical status andprovides means for emergency power shutoff. The CCU has an OperatorConsole with display unit for presenting a depiction of the SROV in itswork environment.

In an extension to the preferred embodiment, independent and specializedHelper Modules having Auxiliary Flanges may be deployed between, andconnected to, sections of the Umbilical. Typically, a Helper Module willbe powered, monitored (via incorporated sensors), and controlled (viaactuators) via the Umbilical. A Helper Module may also incorporate anyof its own MCU, independent intelligence, and power source. A HelperModule may, for example, be a pumping station used to augment pumpingcapacity for the Debris Line over long deployments. As another example,a Helper Module may be incorporate locomotion means (e.g., a motor) foradditional power when deploying or retracting the Umbilical or towingthe SROV. A Helper Module may also incorporate stabilizing means (e.g.,extensible clamps to attach to a conduit wall) so as to stabilize theposition of the Umbilical or Debris Line with respect to the worksurface. In a further embodiment, redundant modules may be configured sothat failure of a module results in failover to the standby, taking thefailed module offline automatically. In a further embodiment, a HelperModule is used on detection of a failed module to deliver a replacementmodule and remove and return the failed module to the MP. Numerous otheruses of Helper Modules will be readily apparent to those of skill in theart.

In another extension to the preferred embodiment, a Strain Relief Moduleis used to detect and relieve strain and stress due to, for example,friction or obstructions on a line linking the Frame Module to the MP,the Frame Module to a Helper Module, or the OC to the MP (e.g., theUmbilical or Debris Line). The Strain Relief Module is preferably anautonomous robot, having independent power, locomotion means, and onboard intelligence. It is preferably attached around the line, andtravels along the line via a motor driving wheels in contact with theexterior surface of the line. On board sensors enable the Strain ReliefModule to monitor stress and strain in the line and to detect upcomingobstructions such as contact with a work surface (e.g., interior of aconduit wall); and to communicate the same with any or all of the othermodules, MP, or OC also connecting with and through that same line. TheStrain Relief Module travels to the part of the line where it is neededand then positions at least a portion of itself between the obstructionand the line, extends extensible arms to stabilize itself with respectto the work surface (e.g., via hydraulic pressure or mechanical clamps).It then disengages its wheels from the motor in such a way that they mayrotate freely and so that the line is provided with relief from stress,strain, friction, abrasion, and the like. The Strain Relief Module mayretract its arms, re-engage its wheels, and reverse its motor so as toreturn to the surface independent of the SROV. Retraction may occur inresponse to receipt of an external command or may be programmed forretraction on detection that the line is being retracted to the surface.Communication with the surface may be effected via (for example)wireless, sonar, or electromagnetic sensor capable of detecting a signalcarried on the electrical power line).

In a further embodiment, additional modules for specialized tasks (itemretrieval, item delivery, etc.) can be created and added, with thedeveloper only having to program the lower level needed for thatmodule's functional operation; this makes the SROV capable of expansiveadaptation to infrastructure-specific tasking.

In an alternative of the preferred embodiment, the highly distributedcontrol architecture is replaced by a more centralized architecture. Inthe distributed architecture, a separate module performs every majorfunction, and that functionality is distributed across three or moretiers of control. In a more centralized architecture, functions may becompressed into fewer or even a single module, and control offunctionality may be provided in a two-tier, or even a single tier ofcontrol.

In an alternative of the preferred embodiment, operating SROV functionsby hydraulic power is replaced by other means. The use of electricity todrive a hydraulic pressure pump is but one means to provide power tooperate SROV functions. Alternative means could include all electric,fuel cell or other new power production technologies, or any hybridcombination (e.g. electric power from the MP to the Frame Module, andfrom the Frame Module to the Shoulder Module, combined with hydraulicpower from the Shoulder Module to a Thruster Module or a Debris RemovalTool).

In an alternative of the preferred embodiment, communication betweenvarious modules and supporting equipment by fiber optic cables isreplaced by other means. Optical fiber is but one means to communicatebetween modules and supporting equipment. Alternative means couldinclude electrical cables, wireless transmission, acoustic coupling, andother methods of signal communication and control. In several furtherembodiments, alternative responses are embedded into the MII to dealwith failures of the SROV, whether from internal or external causes.These include the placement in the Frame module of a ‘state record’,recording device comparable to the ‘black box’ of a jet airliner, whichretains onboard the SROV the sensory records for retrieval after ashutdown, to allow post-incident review and engineering corrections.Another alternative is the incorporation of an internal power source anda set of alternative ‘recovery or retrieval’ options selected by theSROV upon any failure, where the choice of automated response isprincipally driven by the battery state (i.e. available power). Anotheralternative is the incorporation into separable and self-mobile modulesof detachment means and a homing beacon, enabling the slimming of anSROV's profile and dependence upon an external, perhaps wire-driven,retrieval means.

In another alternative to the preferred embodiment, any of a set of SROVself-repair or re-tasking efforts are handled by a specialized module,e.g. a delivery module that brings down thrusters and replaces all thetractors to enable free-swimming propulsion (or vice versa); or replaceschemical with nuclear sensory guides for debris removal tools; orperforms an ‘in-pipe’ substitution and removal of an old and perhapsdamaged articulator or tool module with a new and more apt replacement.

In an alternative of the preferred embodiment, the mechanical apparatusused for debris removal is replaced by other means. The utilization ofmechanical cutting and polishing devices is one device to remove debris.Alternative devices may include other mechanical devices, water jets,laser beams, sonic wave transducers, compressed gases, heat, cold, orany other means for the removal of debris.

In another alternative of the preferred embodiment the mechanicalapparatus used for debris removal is replaced by a conduit-fillingscraping unit (or ‘pig’) connected to the Frame Module or MP throughcommunications, power, and signal lines, and is driven through a portionof a conduit or pulled through a portion of a conduit by pressuredifferential or a prepared traction line to move debris internal to theconduit to a collection location, without losing communication andcontact with the SROV, thereby ensuring continuous feedback and controlreflecting current factors whether such is effected autonomously orunder real-time human direction.

In an alternative of the preferred embodiment, the mechanical collectionof debris in a hopper, pulverizing it in a crushing mill, and pumping itto the surface is replaced by other means. The utilization of theapparatus specified in the preferred embodiment is but one approach.Alternative means may utilize other apparatus, such as a macerator,particulate distributor, or entirely new components and configurationsmay be incorporated, to meet specific job requirements.

In an extension of the preferred embodiment, inspection devices andunits specialized for sensing and measuring may be expanded to includetraction. Propulsion achieved by tracked wheels may be replaced by otherlocomotion means. Other embodiments may utilize additional methods andmeans for determining position, including satellite or other globalpositioning frameworks, sonic, acoustic, laser telemetry, or any otherpracticable means that can provide positional data for the purposes ofnavigation, mapping or control.

In an extension of the preferred embodiment, other hazardousenvironments may require service. Alternative embodiments for hazardousservice duty could include, the interiors of tanks, the holds of ships,the bottoms of settling ponds, mine shafts, tunnels, pipelines, sewers,water mains, areas of radioactivity or high voltage, areas dangerousheights above the water or land, or any other hazardous environment,where infrastructure inspection, repair or maintenance can be conductedto remove humans from exposure to harm, and to incorporate roboticefficiency to increase rates of production over manual processes.

In another embodiment, the Debris Removal Tool hopper is designed tofunnel debris from the conduit by having sides that conform to asignificant portion of a cross section of the conduit, and beingapproximately centered on the axis of the conduit. The hopper sides maybe contracted and expanded as needed to address changes in the geometryor cross section of the conduit.

In an extension to the preferred embodiment, alignment of the means oflocomotion (e.g., drive wheels of the Tractor Tool) with respect to theROV frame may be changed in response to signals (e.g., by issuingcommands from the operator console). In an alternative of the preferredembodiment, traction and propulsion achieved by tracked wheels orpropellers is replaced by other locomotion means. Tracked wheels are butone means of securing and moving the SROV. Alternative means couldutilize vortex generators, pumps, fans, suction pods, water or air jets,electrical motors, electromagnetic units, inch worm units, pneumaticunits, or other developments in the field of traction and propulsion.Other means of locomotion such as, but not limited to, iris-like,flow-driven with insertion from head end of conduit, towing via towline, umbilical, jets, electric motor, propeller, corkscrew, separaterobot, Helper Module, and the like.

In yet another extension to the preferred embodiment, the Umbilical isterminated in a Docking Module to which the SROV frame connects (e.g., aFrame Module). In this case, the Plug and Socket are preferably designedfor submerged quick connect. The Docking Module comprises means toattach stably to the work surface (e.g., conduit or pipe) on command,whereupon the SROV (e.g., the Frame Module) can disengage or undock fromthe Docking Module, perform a work process autonomously, and then returnto dock with the Docking Module, for extraction, recharging, uploadingdata, downloading new instructions (e.g., commands, Solution Patterns,Control Templates, etc.), or moving the Docking Module or Umbilical.This capability is particularly advantageous when addressing surfacesthat cannot be easily remediated by the SROV while attached to andpulling the Umbilical. When the Docking Module includes a DebrisDisposal Tool, it also permits the SROV to move a distance away from theDocking Module, perform a debris removal function, and push debris backtoward the Debris Disposal Tool.

Other embodiments of the SROV may capture and move debris using meansother than crushing and pumping through a Debris Line, and may movedebris to locations other than the surface. For example, in anotherembodiment, the Debris Removal Tool is augmented with means formanipulating and grasping chunks of debris that are not easily crushed,attaching a tow line to them, and towing them to another location,another module, or to the surface. In one embodiment, debris pumpingmeans is augmented by injecting air into the Debris Line, use of anairlift, or jet hoses.

In an alternative embodiment, the -functionality of the MMCU is deployedsuch that every module interacts with every other module on apeer-to-peer basis and shares responsibility for coordinating functions.This embodiment improves upon reliability and robustness at the cost ofimplemented a more complex distributed control system.

In one embodiment, sensors have sufficient intelligence and networkawareness to be connected directly to the Bus and are not necessarilyconnected via a separate Control Unit (e.g., a MCU). In anotherembodiment, all sensor data is communicated between Control Units via acommon digital data format and instructions are communicated betweenControl Units using a common command, actuator, control, and sensorlanguage (e.g., variations and specialization of Actuator ProgrammingLanguage IPL Autonomous Vehicle Control Language, Compact ControlLanguage, GBML, GSML, OpenGIS SENSORML, XML, etc.). Preferably, actuatorcontrol and sensor data are communicated using message-passing and alight weight services-oriented runtime, such as supplied by MicrosoftRobotics Developer Studio™. In a further embodiment, sensor or actuatorprofiles to which instruction executed by Control Units relate,including operating characteristics, operating thresholds and bounds,and the like, may be altered by, for example, loading new profiles intostorage accessible by the Control Unit. In a further embodiment the MPmanages for each Umbilical and Power line a torsional tracing andcurrent strain measurement for that line, to both measure against theoperational safety/wear limits and to guide motion of the SROV at thefar end. In a further embodiment the MP and OC are each able to managemultiple, potentially coordinating, but not overlapping Umbilical andDebris lines, and multiple SROVs. In yet a further embodiment, each OCand MP may also serve as conscious control center for limited-purposesub-modules (independent modules or assemblies not fully integrated withany existing SROV) for activities such as ‘swapping out’ one type ofactuator or tool for another, replacing a damaged unit, or managingsupportive purpose and specialfunctions such as strain relief orline-repair modules as described herein.

In a further embodiment, a damage-limiting seal closes off a plug (andanother for the socket) to avoid internal damage due to separation orpenetration of a module or joint. In a further embodiment, themechanical fasteners that affix the Plug or Socket are selfactuatingupon receiving a connection (or disconnection) instruction, and reporttheir status, and any change therein, to the MCU and thus up to the MMCUand the CCU.

In further embodiment, “self-learning” by the Control Units enablescontinuous improvement for progressive ‘adaptation and improvement’ ofgenerations of modules without requiring overall SROV re-design andremaking. In a further embodiment incorporates a ‘swarm’ of sub-SROVswith specialized limited local tasks (scrubber, watcher, debris hauler)on periodic or task-dependent, automatable subordinate operations. Inyet a further embodiment, the MP and Operation Center have thecapability to operate multiple ‘trees’ and/or ‘nodes’ (e.g., promote andenable ‘swarm’ coordination of multiple SROV units. In a furtherembodiment, layered, multiple-level, hierarchical yet locally-aware;stacks of cycles depending on connections and SROV configuration. Inplace of a single device, the system can become ‘swarm’ and bereconfigured on the fly.

In a further embodiment, a damaged module can be ‘dropped’ and replacedonsite; potentially the damaged module could then auto-return to the MPfor repair. To this end, seals on connectors prevent environmentalhazards from affecting modules on separation. This also allows repairafter accidental disconnects, and reconnects so that a ‘stuck module’need not become a problem on its own.

Throughout this written description of the invention, a describedinstantiations of a single elements (e.g., platform, SROV, component,plug, socket, bus, conductor, module, tool, system, and assembly) isintended to include as a further extension and possibility aninstantiation with multiple elements, so that a ‘platform and module’can also be read as ‘a first and second platform, each with a first andsecond module’. Moreover, the plurality may differ at different levelsfrom one instantiation to the next yet each still should be understoodas a reasonable, merely differentiated extension.

The scope of this invention includes any combination of the elementsfrom the different embodiments disclosed in this specification, and isnot limited to the specifics of the preferred embodiment or any of thealternative embodiments mentioned above. Individual user configurationsand embodiments of this invention may contain all, or less than all, ofthe elements disclosed in the specification according to the needs anddesires of that user. The claims stated herein should be read asincluding those elements which are not necessary to the invention yetare in the prior art and may be necessary to the overall function ofthat particular claim, and should be read as including, to the maximumextent permissible by law, known functional equivalents to the elementsdisclosed in the specification, even though those functional equivalentsare not exhaustively detailed herein.

1.-21. (canceled)
 22. A method, comprising: storing pre-generatedsolution and control commands in an intelligently instrumented commandhierarchy defining a work plan in a storage device of an autonomousrobotic assemblage, where said work plan describes a job to be performedby the autonomous robotic assemblage; self-optimizing the jobperformance by performing the following operations by said intelligentlyinstrumented command hierarchy self-executing at least a firstpre-generated set of commands to perform at least a first autonomousoperation, self-modeling at least a first autonomous performance status,self-adapting the first pre-generated set of commands into at least afirst more-optimized rendition, self-resolving at least a first faultfor at least one of system errors and assemblage collisions involvinginternal articulators or with external objects; and providingtele-operated supervision to allow manual optimization of at least oneautonomous command by an operator.
 23. The method according to claim 22,wherein said autonomous robotic assemblage comprises a robot or othermechanized system incorporating automatable procedures, and at least onemodule that has at least one of (a) a standardized interface to externalsystems and (b) an embedded controller employing at least one tier ofdistribution and incorporating at least one computer.
 24. The methodaccording to claim 22, further comprising performing at least one of thefollowing operations by an operations interface to manage saidautonomous robotic assemblage's self-optimization: supervisingautonomous activities; monitoring status of operational performance; andsupporting tele-operated training and manual override.
 25. The methodaccording to claim 22, further comprising performing operations by amulti-dimensional virtual environment to self-model operational statusbased on at least one event detected from at least one of the following:said autonomous robotic assemblage internal and external operatingconditions; state of said autonomous robotic assemblage articulation andposition; work surface conditions; surrounding work area conditions; thework plan; and data stores supporting the work plan.
 26. The methodaccording to claim 22, further comprising performing an autonomousresolution of at least one operations error.
 27. The method according toclaim 22, wherein said intelligently instrumented command hierarchyadapts to environmental circumstances and changing work conditionsduring at least a first operation of the autonomous robotic assemblagebased on at least a first solution command coordinating andsynchronizing at least a first particular behavior, and at least a firstcontrol command distributing said solution command by real-timereformatting into at least a first translation communicating with atleast a first functional component of said robotic assemblage, andconversely, acquiring status through the intelligent closed-loop sensingof at least a first internal and external experience of said functionalcomponent.
 28. The method according to claim 22, further comprisingself-optimizing at least a first solution command so as to form at leasta first new rendition based on making at least a first improvement to atleast one of the following: work plan performance as a function of goaland objective attainment; breadth of autonomous scope and scale; andresolution of unplanned and unexpected occurrences.
 29. The methodaccording to claim 22, further comprising self-optimizing at least afirst control command so as to form a new rendition based on makingimprovements resultant from at least one of the following: tele-operatedtraining; performance prioritizations derived through analysis ofoperating history and simulations of future potentiality; as applied toat least one of the following: the work plan; solution patterns arisingfrom solution command sets; status and sensory feedback; resolveddeviations between the expected operational state of a solution commandset and the actual operational state of the autonomous roboticassemblage, and any rendition of any of the above.
 30. The methodaccording to claim 22, further comprising self-optimizing thecollaborative coordination of multiple robotic assemblages to mostefficiently perform different aspects of the work plan.
 31. The methodaccording to claim 22, further comprising employing expert systems toexpand a self-optimizing capability selected from the group consistingof coordinating operations, avoiding collisions, enhancing an operatorinterface, correcting errors, creating virtual or simulatedenvironments, and improving work plan and job performance.
 32. A system,comprising: a robotic assemblage comprising a storage device in which anintelligently instrumented command hierarchy stores pre-generatedsolution and control commands that define a work plan, where said workplan describes a job to be performed by said robotic assemblage and saidintelligently instrumented command hierarchy is self-configurable toperform the following operations to self-optimize said job performance:self-executing at least a first pre-generated set of commands to performat least a first autonomous operation; self-modeling at least a firstautonomous performance status; self-transforming at least a firstless-optimized set of commands into at least a first more-optimizedrendition; self-resolving at least a first fault for at least one ofsystem errors, assemblage collisions involving internal articulators orwith external objects; and a tele-operation device configured to enabletele-operated supervision by an operator so that the operator is able tomanually optimize at least one autonomous command.
 33. The systemaccording to clam 32, wherein said autonomous robotic assemblagecomprises a robot or other mechanized system incorporating automatableprocedures, and at least one module that has at least one of (a) astandardized interface to external systems and (b) an embeddedcontroller employing at least one tier of distribution and incorporatingat least one computer.
 34. The system according to clam 32, wherein acontrol console manages said autonomous robotic assemblage'sself-optimization operations by at least one of the following:supervising autonomous activities; monitoring status of operationalperformance; and supporting tele-operated training and manual override.35. The system according to clam 32, wherein a multi-dimensional virtualenvironment self-models operational status based on at least one eventdetected from at least one of the following: said robotic assemblageinternal and external operating conditions; articulation andpositioning; surrounding work area and work surface conditions; the workplan; and content of a data store.
 36. The system according to claim 32,wherein an autonomous operation resolves a monitored error.
 37. Thesystem according to claim 32, wherein said intelligently instrumentedcommand hierarchy adapts to environmental circumstances and changingwork conditions during at least a first operation of the autonomousrobotic assemblage based on at least a first solution commandcoordinating and synchronizing at least a first particular behavior, andat least a first control command distributing said solution command byreal-time reformatting into at least a first translation communicatingwith at least a first functional component of said robotic assemblage,and conversely, acquiring status through the intelligent closed-loopsensing of at least a first internal and external experience of saidfunctional component.
 38. The system according to claim 32, whereinself-optimizing at least a first solution command so as to form at leasta first new rendition based on making at least a first improvement to atleast one of the following: work plan performance as a function of goaland objective attainment; breadth of autonomous scope and scale;resolution of unplanned and unexpected occurrences.
 39. The systemaccording to claim 32, wherein self-optimizing at least a first controlcommand so as to form a new rendition based on making improvementsresultant from at least one of the following: tele-operated training;performance prioritizations derived through analysis of operatinghistory and simulations of future potentiality; as applied to at leastone of the following: the work plan; solution patterns arising fromsolution command sets; status and sensory feedback; resolved deviationsbetween the expected operational state of a solution command set and theactual operational state of the autonomous robotic assemblage, and anyrendition of any of the above.
 40. The system according to claim 32,wherein a collaborative coordination of multiple robotic assemblages aredynamically optimized to perform different aspects of the work plan. 41.The system according to claim 32, wherein expert systems are employed toexpand a self-optimizing capability selected from the group consistingof coordinating operations, avoiding collisions, enhancing an operatorinterface, correcting errors, creating virtual or simulatedenvironments, and improving work plan performance.